class sugar

Allen Wirfs-Brock allen at wirfs-brock.com
Thu Jun 16 21:43:17 PDT 2011


On Jun 16, 2011, at 8:34 PM, Christopher M. Balz wrote:

> Thanks Allen.  The new 'Object.create' functionality you bring up is certainly important to this discussion.  It still leaves inheritance mechanics such that they must be performed imperatively, instead of specified declaratively.  I think that we can dispense with such arrangements, with JavaScript framework class engines, and not least with actual native 'class' syntax by basically just adding a declarative annotation such as 'nonshared' in front of mutable 'this' properties of objects.  
> 
> For example, instead of this current situation (note the undesirably shared mileage in the example below):
>     
> 
>     oAuto = {
>         oEngine : { iMiles : 0 }
>     };
> 
>     oCar = Object.create( oAuto );
> 
>     oMyCar = Object.create( oCar );
>     oMyOtherCar = Object.create( oMyOtherCar );
do you mean:  oMyOtherCar = Object.create(oChar);  or perhaps: oMyOtherCar = Object.create(oMyChar)

> 
>     oMyCar.oEngine.iMiles    
>     0
>     oMyCar.oEngine.iMiles = 10000;
>     oMyCar.oEngine.iMiles
>     10000
>     oMyOtherCar.oEngine.iMiles
>     10000
> 
>   - we could instead keep to a pure prototype-based inheritance model but not have the above issue of undesired sharing by doing something declarative as in the example code below that uses a 'nonshared' annotation:
> 
>     oAuto = {
>         @nonshared oEngine : { iMiles : 0 }

Yes, but what is the non-shared semantics.  It presumably creates a own property in a derived object but how is that property initialized.  Is some sort of copy performed on the current value of the original property.  Or is the the original initialization code for the property re-evaluted to initialize the new own property.  What if some sort of invariant needs to be maintained among the values of multiple properties.

All these issues are presumably why self delegates the "copy" semantics for creating a new instance derived from a prototype to the prototype.  Only the prototype knows how to initialize non-shared state that is derived from it.  It is easy to make new property slots.  It's hard to know what values to place in them.

This is really the same as a subclass constructor need to call the superclass constructor.  It is the superclass that  knows how to initialize the instance variables it provides to the subclass



>     };
> 
>     oCar = Object.create( oAuto );
> 
>     oMyCar = Object.create( oCar );
>     oMyOtherCar = Object.create( oMyOtherCar );
> 
>     oMyCar.oEngine.iMiles
>     0
>     oMyCar.oEngine.iMiles = 10000;
>     oMyCar.oEngine.iMiles
>     10000
>     oMyOtherCar.oEngine.iMiles
>     0
> 
> This keeps JavaScript "simple" but adds the one major feature not currently supported by prototypes, unique copies of inherited objects.  Also, it greatly extends the utility of 'Object.create' by avoiding the current necessity to use imperative code to get desired inheritance results.  
> 
> As I mentioned above in an earlier post in this thread, inadvertent sharing due to misplaced imperative commands, and even the need to do that kind of housekeeping work, has been seen to warrant class syntax (both native and JavaScript-framework supported).  But class syntax then requires "fixing" the constructor property, possibly adding the superclass call to every constructor, and in general, supporting a construct that seems less and less in demand in the developer (JavaScript user) community.

I think the imperative initialization is always going to be necessary.  You can declarative identify which property need to be replicated but initializing them takes imperative code.   This is the case whether your mechanism is prototypal inheritance or class inheritance.

BTW, for another take on how we might emphasize prototypes rather than classes see my recent "Prototypes as the new class declaration" post.

Allen







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110616/43861722/attachment.html>


More information about the es-discuss mailing list