On Sun, Sep 5, 2010 at 6:33 PM, Mark S. Miller <erig...@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@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
