-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
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
Private constructor short comings #3
Comments
It is not great, but it is ok with me because that is what we already get for abstractions like ArrayIterator that are represented by a prototype but no constructor. [][Symbol.iterator]().constructor; // Object constructor If we do as you suggest, then we would also need to give these an overriding If we are indeed ok with consistency-with-precedent, then Attn: @dtribble |
What would be exposed through the inherited constructor property for a instances of a subclass of a class that has a private constructor? e.g.,
|
It would still be the |
Private constructors would have the referencing problems discussed more generally in #2 for prototype placement private methods.
Also, if
#constructor() {}
just created a private #constructor field and suppresses the conventional prototype level constructor property, then instances of most such class would still expose an inherited constructor property. Is that ok with you?Consider:
It seems what a developer would really want in this situation is something that is semantically equivalent to:
But, I would be reluctant to make
#constructor() {}
special like that. Perhaps this is a situation where a decorator would be a better way to hide a constructor:However, I'm also leery of using (built-in?) decorators like this to do things that feel like they should be core to the declarative structure of the language. I'd prefer to reserve decorators for use by frameworks and for application level metaprogramming.
The text was updated successfully, but these errors were encountered: