You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hmm, I wasn't thinking of making limitations on this. Do you think there should be? What sorts of guarantees would that lead to? (A constructor can recurse anyway...)
I don't mean any of that, it's just that if we made such a restriction, it would be possible for the constructor to make further calls to new, and use that to class.instantiate many objects, the same as if we don't have the restriction.
oh sure, i ts not like restricting this to one call prevents multiple calls - a dev can always construct classes in a loop and instantiate multiple objects. It’s more like, super() can only be called once, so what’s the use case for calling this more than once? How likely is it that calling it more than once is a bug, versus being intentional? If the intentional use case is rare enough, and still possible just with more boilerplate, and the buggy case is more common, then it seems beneficial to ensure it’s only called once (also, that you can’t both call it, and super(), on the same instance)
I'm not sure what sort of invariants it would provide to prevent new.initialize from being called on multiple objects. Without this feature, a constructor may recurse, and so in conjunction with the super return trick, it could (contortedly) achieve the same effect.
Activity
littledan commentedon Jan 6, 2019
Hmm, I wasn't thinking of making limitations on this. Do you think there should be? What sorts of guarantees would that lead to? (A constructor can recurse anyway...)
ljharb commentedon Jan 7, 2019
Can you elaborate on a constructor recursing? Circular prototype chains are forbidden and the super return trick would only work on one object, no?
littledan commentedon Jan 7, 2019
I don't mean any of that, it's just that if we made such a restriction, it would be possible for the constructor to make further calls to new, and use that to class.instantiate many objects, the same as if we don't have the restriction.
ljharb commentedon Jan 7, 2019
oh sure, i ts not like restricting this to one call prevents multiple calls - a dev can always construct classes in a loop and instantiate multiple objects. It’s more like, super() can only be called once, so what’s the use case for calling this more than once? How likely is it that calling it more than once is a bug, versus being intentional? If the intentional use case is rare enough, and still possible just with more boilerplate, and the buggy case is more common, then it seems beneficial to ensure it’s only called once (also, that you can’t both call it, and super(), on the same instance)
jridgewell commentedon Feb 1, 2019
Note that if any fields are private,
PrivateFieldAdd(which defines the field on the object) will throw on second attempt (test262).ljharb commentedon Feb 1, 2019
That’s good to know; i was also thinking of preventing it from being called on two different objects.
littledan commentedon Feb 4, 2019
I'm not sure what sort of invariants it would provide to prevent
new.initializefrom being called on multiple objects. Without this feature, a constructor may recurse, and so in conjunction with the super return trick, it could (contortedly) achieve the same effect.