Open allenwb opened 7 years ago
Is that ok with you?
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 .constructor = undefined
.
If we are indeed ok with consistency-with-precedent, then #constructor
still makes sense.
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 Object
constructor
Private constructors would have the referencing problems discussed more generally in https://github.com/erights/Orthogonal-Classes/issues/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.