Ok I wrote up another gist https://gist.github.com/7e649e8c33d412e90178
that no longer refers to any non-existing functions like `Function.create` and addresses `super` sugar issue using `base` function (In a similar way as in Dmitry's link). Also, implementation uses deprecated `caller`, non-standard `__proto__` , pseudo internal properties [[target]]', '[[name]]', '[[this]]' and function wrappers, but I hope / assume native implementation will be able to achieve same results without any of those. One disadvantage in comparison to `super` is that you can no longer call overlaid X methods from Y method, from my experience thats pretty rare case and can easily be workarounded. Alternatively base can have be improved using proxies to support base[X](a, b) case as well. Regards -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ Address: 29 Rue Saint-Georges, 75009 Paris, France (http://goo.gl/maps/3CHu) On Monday, 2011-06-13 at 24:49 , Brendan Eich wrote: > On Jun 12, 2011, at 3:38 PM, Irakli Gozalishvili wrote: > > > On Monday, June 13, 2011, Brendan Eich <[email protected] > > (mailto:[email protected])> wrote: > > > On Jun 12, 2011, at 3:18 PM, Irakli Gozalishvili wrote: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. > > > Ok. But what is that Function.create your gist relies on? > > > > > > It was proposed before I believe, it's like Object.create > > > > > > Function.create = function (proto, func) { > > var f = function() { > > return func.apply(this, arguments); > > } > > f.__proto__ = proto > > return f > > } > > No, that was too proxy-like. See > > http://wiki.ecmascript.org/doku.php?id=strawman:name_property_of_functions > > Starting at "The major objection to losing ...." > > > > > Another idea I had was that super can be similar to private. Here is some > > > example: > > > Please note that the private(this)/private(other) syntax is intentional > > > straw, to be burned up and replaced with something better. > > > I think you're trying to self-host too much. People can write classes the > > > hard way, with super too. They need sugar, not salt or pepper ;-). > > > /be > > > > I just don't know how wild I can go with idea :) Isn't it better to > > leave off super for the moment and tackle that separately ? > > Not obviously. super outside of classes does not necessarily pay for itself > (I did not remember it going to Harmony at the last meeting). And super > inside of class should pay off as the classes proposal hopes -- 'super' in > that context has no open issues. > > /be > /be
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
