Is class syntax really necessary ?

Dmitry A. Soshnikov dmitry.soshnikov at
Sun Jun 12 14:43:27 PDT 2011

On 13.06.2011 1:18, Brendan Eich wrote:
> On Jun 12, 2011, at 2:22 AM, Irakli Gozalishvili wrote:
>> Hi,
>> Is there anything else (other than starting this thread) I can do to 
>> make committee consider `Function.prototype.extend` as an alternative 
>> to a proposed class sugar ?
> Could you show Function.prototype.extend again, and say how it solves 
> the super-construct and super-method-call problems?

If interested, I know at least three versions of normal `super` sugar in 
ES3 code:

1. using wrappers for every descendant method with the same name (the 
technique is to (a) set `this.super` to parent, (b) activate parent 
method and get result, (c) return result to child)

2. using `Object.prototype` to store `super`

3. using `arguments.caller` (banned in ES5-strict, non-standard in ES3, 
but I normally used it in my projects)

If will be needed, I can write the code for all three techniques (the 
later though can be found here:

That is, it's not actually the main issue, we normally can write in 
ES3/5 code something like this:

var Foo = Class({
   constructor: function (a) {
     this.a = a;
   activate: function () {
     return this.a;

var Bar = Class({
   constructor: function (a, b) {
     this.b = b;
   activate: function () {
     console.log(this.b + this.super());

var bar = new Bar(10, 20);
bar.activate(); // 30!

P.S.: of course this.super() is much more convenient than (real code 
from e.g. ExtJS) `Bar.superclass.constructor.apply(this, arguments)` 
(what? are you kidding me, guys? Seems you just like syntactic noise). 
But unfortunately because of hack-nature (`caller` is not-standard and 
banned, people afraid to augment `Object.prototype`, wrappers are not so 
efficient), so it's not e.g. for cross-browser code. Though, I was 
pleased to use it in my library in the project where I had 
SpiderMonkey-only stuff (patched Thunderbird), so there I used that 
`this.super` actively (OK, actually `this._super`, because only since 
ES5 we can use keywords as properties).

However, regardless that we _can_ implement convinient and sugared super 
calls as a library, classes from the box will be more convenient IMO.


> /be
>> Thanks
>> --
>> Irakli Gozalishvili
>> Web:
>> Address: 29 Rue Saint-Georges, 75009 Paris, France 
>> <>
>> 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
>>> es-discuss at <mailto:es-discuss at>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at <mailto:es-discuss at>
> _______________________________________________
> es-discuss mailing list
> es-discuss at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list