Skip to content
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

Open
allenwb opened this issue Jan 30, 2017 · 3 comments
Open

Private constructor short comings #3

allenwb opened this issue Jan 30, 2017 · 3 comments

Comments

@allenwb
Copy link
Contributor

allenwb commented Jan 30, 2017

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:

class Foo {} {
   #constructor() {}
}
console.log((new Foo()).constructor === Object);  //true

It seems what a developer would really want in this situation is something that is semantically equivalent to:

class Foo {} {
   constructor() {}
}
Foo.prototype.constructor = undefined;

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:

class Foo {} {
   @hide constructor() {}  //sets constructor property of prototype object to undefined
}

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.

@erights
Copy link
Owner

erights commented Feb 8, 2017

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

@dtribble
Copy link

dtribble commented Feb 8, 2017

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.,

  • class weakRef has a hidden constructor.
  • class myWeakRef has a hidden constructor
  • client retrieves the "superclass constructor property" on an instance of myWeakRef

@erights
Copy link
Owner

erights commented Feb 8, 2017

It would still be the Object constructor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants