On Mar 21, 2012, at 6:35 AM, Kevin Smith wrote:
> Hi Axel,
>
> We should probably hold off on private and static member syntax until there's
> consensus on the other open issues:
>
> - "constructor" vs. "new" (Dave and I say "new", Allen says "constructor";
> mostly aesthetic - can be put off for now)
> - class-side inheritance? (Mark and I say no, Allen and Russell say yes)
> - What restrictions for RHS of "extends"? Must it be a constructor?
> (Russell and I say yes)
>
> Additionally, I'm still worried about how we call the superclass constructor:
>
> new() {
> // do arbitrary stuff here
> super(...);
> }
>
> This would potentially allow a superclass instance method to be called before
> the superclass initialization has completed. If we want to maintain the
> invariant (as it seems most class-based languages do) that methods can only
> be called after initialization has completed, then this won't work. Thoughts?
This invariant can is difficult, if not impossible to maintain. Even the
concept of "initialization has completed" is difficult to define. My
experience is 10 years out of date, but I know that Java was not successful at
maintaining that invariant.
Note that this invariant is probably most important for static languages that
depend upon initialization invariants for memory safety. ES does not have this
issue and the langue runtime level, although there could of course be
application level invariants that are violated.
It is actually sometimes quite useful to do some processing before invoking
super initialization:
constructor (...args) {
let processedArgs = preprocessToBeAcceptableForSuper(args);
super(processedArgs);
...
}
My sense is that this invariant is a very minor issue some language designers
send a lot of time worry about either come up with a solution that really does
n'twork or which eliminates more useful usage patterns than than elimiante
hazards.
Both Ruby and Smalltalk support arbitrary placement of super initialization
calls (if any) and at least for Smalltalk is was not a major source of
problems..
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
