class sugar

Mark S. Miller erights at google.com
Sat Jun 4 00:28:08 PDT 2011


On Sat, Jun 4, 2011 at 12:04 AM, Mark S. Miller <erights at google.com> wrote:

> On Fri, Jun 3, 2011 at 9:43 PM, Peter Michaux <petermichaux at gmail.com>wrote:
>
>> JavaScript has two well-known ways of doing object construction that
>> could be argued to be class-like. (Trying to be careful with wording
>> here.) There is the new/prototype/this-based system and there is the
>> closure-based system.
>>
>> new/prototype/this-based system -----------------------
>>
>> function Point(x, y) {
>>    this.x = x;
>>    this.y = y;
>> };
>>
>> Point.prototype.getDistance = function() {
>>    return Math.sqrt(this.x * this.x + this.y * this.y);
>> };
>>
>
>
> which can be expressed in classes as:
>
>   class Point {
>     constructor(x, y) {
>       public x = x;
>       public y = y;
>     }
>     getDistance() {
>       return Math.sqrt(this.x * this.x + this.y * this.y);
>     }
>   }
>
>
>
>
>>
>>
>> closure-based system ----------------------------------
>>
>> function makePoint(x, y) {
>>    return {
>>        getDistance: function() {
>>            return Math.sqrt(x * x + y * y);
>>        }
>>    };
>> }
>>
>
>
> which can be expressed in classes as:
>
>   class Point {
>     constructor(x, y) {
>       public getDistance() {
>         return Math.sqrt(x * x + y * y);
>       }
>     }
>   }
>
>
>
>>
>>
>> The classes strawman is proposing terse syntax to make the
>> new/prototype/this-based system more aesthetic.
>>
>> http://wiki.ecmascript.org/doku.php?id=harmony:classes
>>
>>
>> Introducing class syntax will be one of the most monumental changes
>> ever made to ECMAScript and I suggest that unfortunately the proposal
>> is targeting the wrong version of creating constructors. I've found
>> the closure-based system more compelling than the
>> new/prototype/this-based system. My memory even makes me think that
>> this list was heading in the direction of sugaring the closure-based
>> system in 2008.
>>
>> http://www.mail-archive.com/es-discuss@mozilla.org/msg00335.html
>>
>> Was using class syntax to sugar the closure-based system thrown out as
>> a possibility for some reason?
>>
>
> Hi Peter, your memory is correct and the classes design has had a tortuous
> history responding to many pressures. As you see from my rewrite of your two
> examples above, the design we ended up promoting to harmony can express
> both. While I agree that the objects-as-closure approach is more elegant, it
> is less common. Most class-like code today is expressed in the
> prototype/this-based style. As discussion continued among various committee
> members, it became clear that a class proposal that served only the
> objects-as-closures proposal could not achieve consensus. It also became
> clear that we could adopt a proposal that served only the prototype/this
> style. I'm glad to say that we did much better than that.
>
> Some great virtue of the classes proposal that we adopted are that
> * it can express the more common prototype/this-based style in a terse and
> clear manner.
> * code in the prototype/this-based style of classes can trivially be as
> efficient as the corresponding common pattern is today, without arduous VM
> changes
> * classes can interoperate in both directions with old conventional
> prototype/this-based code
> * objects-as-closures can still be expressed
> * both patterns support string encapsulation
>

Should be: *strong* encapsulation


>   a) prototype and instance methods can access "private(this)"-based
> class-private instance variables.
>   b) instance methods can access lexically captured instance-private
> instance variables
> * both patterns support high integrity in the context of a "const class".
> * And perhaps most important, that it serves all these purposes with a very
> simple design.
>
> Personally, for new code that does not need to interoperate with old
> prototype/this-based code and does not need to be super high performance, I
> will always use the objects-as-closures pattern. For users like us, this
> accepted class proposal has the following disadvantages:
> * code in the objects-as-closure style is more verbose than it would have
> been in earlier proposals, but not too bad.
> * code in the objects-as-closure style is less likely to be efficient,
> because the efficiency already supported by the other style removes the
> pressure implement the optimizations needed to make the objects-as-closure
> style efficient. (Of course, these optimizations are no less possible than
> they were in the earlier proposals, it's just that they're less likely to
> happen.)
>
> Altogether, given my weightings of these pros and cons, I am extremely
> happy with these tradeoffs.
>
> --
>     Cheers,
>     --MarkM
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110604/dc556cbe/attachment.html>


More information about the es-discuss mailing list