class sugar

Christopher M. Balz christophermbalz at
Fri Jun 17 18:24:13 PDT 2011

> do you mean:  oMyOtherCar = Object.create(oChar);  or perhaps: oMyOtherCar = Object.create(oMyChar)

Per Allen's question, yes, typo on my part - I meant:

     oMyOtherCar = Object.create( oCar );

So, both 'oMyOtherCar' and 'oMyCar' are created from the same prototype.

> Yes, but what is the non-shared semantics.  It presumably creates a own property in a derived object but how is that property initialized.

That's what my suggestion intends.  It would be either a deep copy made at creation time, or alternatively would work like immutables inherited from the prototype chain apparently do now: The unique (and deep) copy would only be made in an inheriting object if a property of the non-shared mutable were changed.  

> Only the prototype knows how to initialize non-shared state that is derived from it.

This would be a declarative way to streamline that process, which, granted, would not be as flexible since it cannot take parameters from an inheriting object.  The values copied into the inheriting object would be simply what exist in the provided prototype object - in this case, the property 'oEngine'.  

> What if some sort of invariant needs to be maintained among the values of multiple properties.

I'm not sure why maintaining an invariant would be hard in this case.  If you mean a constant or final value, I would think that characteristic would be carried along in the copy operation.  Sorry if I'm missing something there.

> It is the superclass that  knows how to initialize the instance variables it provides to the subclass

In this example, the prototype could have a 'drive' method that would increment the 'iMiles' property on 'oEngine'.  But 'drive' isn't an initialization method; it's run-time.  Certainly, imperative code (such as in an 'init' method or in class semantics, a 'constructor') could be used to perform init-time modifications.  But making non-shared mutable (e.g., object) properties should be easier than remembering to do that all the time non-shared object properties are needed, especially because there are many cases such as the car mileage example where no special initialization is required (miles are set to zero on construction).  

Mainly though, making it easy to mark a mutable as non-shared removes, at least as I see it, a major pitfall for JavaScript users where they create mutables in inheritance hierarchies without realizing that they are shared amongst inheriting instances.  Even if the developer (JavaScript user) knows that mutables are shared by default, it's easy to forget to make a 'constructor' or 'init' method to stamp out unique copies and then to be sure to invoke that in subclasses/inheriting objects.  A failure on either end results in a bad bug.
> All these issues are presumably why self delegates the "copy" semantics for creating a new instance derived from a prototype to the prototype.

Thanks for pointing that out in your earlier post in this thread.  Your recent "Prototypes as the new class declaration" post looks great.  Although I don't yet understand the entirety of it - for example, why use 'constructor' instead of 'copy' if the focus is to be prototypes instead of classes?  But possibly the other thread would be the place for that question.

More information about the es-discuss mailing list