Finding a "safety syntax" for classes

Allen Wirfs-Brock allen at wirfs-brock.com
Wed Mar 21 11:45:06 PDT 2012


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




More information about the es-discuss mailing list