class sugar

Christopher M. Balz christophermbalz at stanfordalumni.org
Thu Jun 16 20:34:56 PDT 2011


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 );

    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 }
    };

    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.
 
  - cb
________________________________
From: Allen Wirfs-Brock <allen at wirfs-brock.com>
To: Allen Wirfs-Brock <allen at wirfs-brock.com>
Cc: Christopher M. Balz <christophermbalz at stanfordalumni.org>; ECMAScript-Discuss <es-discuss at mozilla.org>
Sent: Monday, June 6, 2011 11:48 AM
Subject: Re: class sugar

and another...
On Jun 6, 2011, at 11:44 AM, Allen Wirfs-Brock wrote:

> (correction copy function below)
> On Jun 6, 2011, at 10:58 AM, Allen Wirfs-Brock wrote:
> 
>> 
>> On Jun 5, 2011, at 7:50 PM, Christopher M. Balz wrote:
>> 
>>> Are there proposals for fixing, without going as far as making a 'class' system, the major drawback of prototype-based inheritance: Without something like a JavaScript (js) class factory (a class factory as provided by most js frameworks) to provide inheriting instances their own copies of mutables (objects, as distinguished from immutables such as strings, numbers, and functions), all inherited mutables are always shared by all inheriting instances, even when modified by a single inheriting instance.  The problem does not exist with immutables, as unique copies are bestowed upon an inheriting instance (as I understand it) if and when it modifies the property.
>>> 
>>> ...
>>> Summing up, it seems that adding 'class', while very helpful for the vast majority of developers who have been trained in Java and C++, does stray far from the original intent of simplicity of what I understand to be one of the inspirations for JavaScript, 'Self' (e.g., "Self: The Power of Simplicity", http://labs.oracle.com/self/papers/self-power.html).   And the center of gravity may have shifted toward JavaScript enough that 'class' may no longer be as needed by the user community as it was even a couple years ago.  So I think it would be better if 'class' could be avoided and instead, the few drawbacks I mention above fixed with some choice keywords (for example, a keyword to mark a mutable (object) property of a prototype instance such that inheriting instances would get their own unique copies of it).  That would enable many or most of the benefits of a 'class' system, while preserving the simplicity of the unity of type and instance that
 was
>>> one of the original selling points of 'Self'.  
>> 
>> In self, this problem seems to be address by the object creation convention.  New objects are created by invoking the "copy" method on the intended prototype object.  Every such object is expected to define an appropriate copy method that takes care of copying non-sharable mutable state. In JavaScript terms:
>> 
>> 
>> Object.prototype.copy = function () {return Object.create(this)};
>> 
>> var Polygon = {
>>  vertices: [{x:0,y:0}, {x:1,y:0}, {x:1,y:1}],  //default is a unit right triangle
>>  copy: function() {
>>       var newPoly = super.copy();  //proposed for ES.next, in ES 3/5 say: Object.prototype.copy.call(this)
>>       newPoly.vertices = this.vertices.copy();
             return newPoly;
>>   }
>> }
>> 
>> var mySquare = Polygon.copy();
>> mySquare.vertices[3]={x:0,y:1};
>> 
>> Allen
>> 
>> 
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
> 



More information about the es-discuss mailing list