Classes as Sugar is now ready for discussion

Dmitry Soshnikov dmitry.soshnikov at gmail.com
Thu Sep 9 12:35:00 PDT 2010


On Sun, Sep 5, 2010 at 6:33 PM, Mark S. Miller <erights at google.com> wrote:

> http://wiki.ecmascript.org/doku.php?id=strawman:classes_as_sugar
>
> * Classes as Sugar
>
>
All this looks a bit strange. From several positions.

First, combination of classes and prototypes. Currently, the paradigm used
in ECMAScript with delegation based prototypes does not differ much from a
class-based paradigm with "first-class" dynamic classes. The good example is
Python.

You won't find a big difference between Python's ("first-class" dynamic)
classes and prototypes+constructor in ECMAScript. Thus, the major aspects
should be considered: methods/properties resolution and code-reuse
stylistics. In both, ECMAScript and Python, a delegation based inheritance
is used to achieve both objectives. I.e. Python's classes are just syntactic
sugar of delegation based model used in ECMAScript.

Thus (the lacks of your desugarred code):

1. you don't have a good code-reuse mechanism (which should be used the same
-- a delegation to a class/prototype), i.e. every returned frozen instance
has own properties/methods that is non efficient.

2. you don't have an inheritance (again code-reuse, but the code of parent
prototypes).

Both lacks may be avoided even in ES5 implementation. Though, the desugarred
code will look ugly (with passing private state of objects to be able place
all methods -- private and public in to the prototype (public methods) and
its surrounding environment (private methods), having only one instance of a
method for for a class). Using new things such Names or WeakMaps possibly
it's even easier to achieve.

In your approach, there is a code-reuse, but it's made as cloning, but not
dispatching. Cloning (concatenative prototypes) is faster, but very
inefficient by memory. So, it's even may be called a "smart copy-paste", but
not "reuse" (of the same memory).


> The part of this strawman I am least happy is the rules of "this" at <
> http://wiki.ecmascript.org/doku.php?id=strawman:classes_as_sugar#delicate_self_reference>.
> Suggestions appreciated. Thanks.
>
>
The second one issue is that the sugar is not so sugarred. I think it should
syntactically be minimalistic and do not use several forms of
methods/functions (that will avoid the problem with /this/ value).

As I see it:

class Point(x, y) {

  private:

    var x = 10
    var y = 20

    function calculate(z) {
      var x = 30
      // use "this" to refer instance
      // properties and distinguish from
      // local var of a function
      this.x + this.y + x + z
    }

  public:

    var z = 30

    function foo(z) {
      this.bar() + this.calculate(z);
    }

    const function bar() {
      this.z + 10
    }

}

class MyPoint(x, ...args) inherits Point {
  public:
    function foo() {
      super(this.x) + 30
    }
}

Formal parameters may be moved to the initialize method. Also function
expressions may be used to define a method conditionally:

class MyPoint inherits Point {

  public:

    function initialize(x, ...args) {
      this.x = x;
    }

    function foo() {
      super(this.x) + 30
    }

    // a FE
    function bar = debug ? (x, y) { ...} : (x) { ... };
}

P.S.: I mean, if you want a classes-sugar, then it really should be a shugar
and use all related things, including code-reuse implemented as delegation
based inheritance (thus a prototype may be frozen for static classes and not
-- for dynamic).

Dmitry.

-- 
>     Cheers,
>     --MarkM
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100909/7f237270/attachment.html>


More information about the es-discuss mailing list