GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The long-awaited text on why constructors are good.
Use sentence case for all section titles
Separate out surface concerns from deeper concerns
Classes should have constructors whenever possible
Closes #51. Closes #77.
Meta: export "custom elements" and window.open()
Useful for w3ctag/design-principles#80.
Because a class can be so easily defined in IDL, and because those classes end up in all global scopes, there needs to be strong advice to really generalize classes for maximum reuse (i.e., WG should talk to the community!)... and that "data only" classes, should just use Dictionaries (i.e., objects). Payment Request has the worst of both, for example: PaymentAddress is non-constructible, and pure data... it's tragic :(
You should still be able to fix that, no?
If you mean adding a Constructor on these interfaces, then yes. We should probably do that -as it would not break anything, I think.
I meant turning them into a dictionary if they're just data.
No, unfortunately. Couple of reasons:
PaymentAddress does seem like a strange mix of dictionaries and classes.
However, as discussed elsewhere I don't think we should be returning dictionaries from APIs in general as it makes it impossible to add methods to them in the future. Using dictionaries as arguments to functions as a way of having optional values sounds fine though.
This might actually be a thing the TAG should have a design principle by itself. @slightlyoff @domenic
It doesn't make it impossible; it just means you have to upgrade to a class at that time.
nit: "reified" seems like fancy jargon (specially because it conjures up "semantic web reification" 🤢). Is there a simpler term we can use here? If no, that's ok.
Merge branch 'master' into constructors
IMO, this is the primary reason to pushback on live collections. It's not the global performance cost though, it's that the performance cost is action at a distance, e.g. holding on to NodeLists makes completely unrelated methods, e.g. appendChild, slow in a way that's non-obvious.