On Monday, 2011-06-13 at 24:03 , Brendan Eich wrote:
> On Jun 12, 2011, at 2:52 PM, Irakli Gozalishvili wrote: > > > > Here is gist I wrote before: > > > > https://gist.github.com/986487#file_implementation.js > > > > > > > What Function.create are you using there? > > Is there a missing return statement in function extend? > > Yeap, sorry! It's there now. > > > and say how it solves the super-construct and super-method-call problems? > > > > > > > > > > > > > > > I don't have any (in js implementable solution) for those problems, also I > > think sugar for `super` can be a separate thing. Gist contains example with > > super that behave exactly the same as in harmony proposal for classes. > > super.update(); > // Desugars to: > // Object.getPrototypeOf(Object.getPrototypeOf(this)).update.call(this); > > > That comment is wrong, or worse: it implies the wrong spec. This function > code does not want to depend on |this|, which could be rebound. You want to > depend on the [[Prototype]] of the enclosing object, or if contained in class > C syntax at the right level (not nested in arbitrary function expressions or > inner function definitions), C.prototype.[[Prototype]]. > > Allen worked through this idea already: > > http://wiki.ecmascript.org/doku.php?id=harmony:object_initialiser_super > Could be, I have not spend time thinking on super as I considered as separate issue. I'll take a look at Allen's work thanks for the link. Another idea I had was that super can be similar to private. Here is some example: function super(self) { var proto = Object.getPrototypeOf(Object.getProtypeOf(self)); Proxy.create({ ... get: function (receiver, name) { // Shorter to constructor would be nice: super(this).new(options) if (name === 'new') name = 'constructor' // make sure to apply for getter / setters / and methods only. // super(this).method(a, b) return proto[name].bind(self); } ... }, proto); } super(this).new(options); super(this).constructor(a, b); super(this).method(a, b); Obviously I don't suggest to use proxy, I just used to illustrate idea. Also please not that constructor will be enough as users will be able to implement getter `new` returning `this.constructor` on a base class for shorter syntax. > /be > > > > > /be > > > > > > > > > > > Thanks > > > > -- > > > > Irakli Gozalishvili > > > > Web: http://www.jeditoolkit.com/ > > > > Address: 29 Rue Saint-Georges, 75009 Paris, France > > > > (http://goo.gl/maps/3CHu) > > > > > > > > > > > > On Tuesday, 2011-05-24 at 24:48 , Brendan Eich wrote: > > > > > > > > > On May 23, 2011, at 11:25 AM, Bob Nystrom wrote: > > > > > > > > > > > One thing I'd like the proposal to support, which it doesn't > > > > > > currently, is initializers on instance property declarations. Then > > > > > > you could do: > > > > > > > > > > > > > class C { > > > > > > > public _list = []; > > > > > > > > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > With that, you'll correctly get a new _list on each instance of C > > > > > > when it's created. > > > > > But (we've argued, I forget where so repeating it here), this looks > > > > > like [] is evaluated once when the class declaration is evaluated. > > > > > That is not what you intend. > > > > > > > > > > Then at some point (in the last thread on this) I remembered > > > > > parameter default values, but they cover only missing parameters to > > > > > the constructor. This _list member could be private. But it has to be > > > > > initialized in a body that executes once per instantiation, which is > > > > > not the class body -- it's the constructor body. > > > > > > > > > > /be > > > > > _______________________________________________ > > > > > es-discuss mailing list > > > > > [email protected] (mailto:[email protected]) > > > > > https://mail.mozilla.org/listinfo/es-discuss > > > > > > > > _______________________________________________ > > > > es-discuss mailing list > > > > [email protected] (mailto:[email protected]) > > > > https://mail.mozilla.org/listinfo/es-discuss > > > > > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
