On Jun 12, 2011, at 3:38 PM, Irakli Gozalishvili wrote: > On Monday, June 13, 2011, Brendan Eich <[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
