Is class syntax really necessary ?

Brendan Eich brendan at mozilla.com
Sun Jun 12 15:49:15 PDT 2011


On Jun 12, 2011, at 3:38 PM, Irakli Gozalishvili wrote:

> On Monday, June 13, 2011, Brendan Eich <brendan at mozilla.com> 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


More information about the es-discuss mailing list