Minimalist (why) classes ?

Brendan Eich brendan at
Sun Nov 13 21:49:21 PST 2011

On Nov 13, 2011, at 9:42 PM, Irakli Gozalishvili wrote:

> I think this discussion drifted into slightly diff direction. 
> What I intended to say was that today all major frameworks use same patter to do subclassing. They all implement different APIs to do the following:
> function subclass() {
>    // init ….
> }
> subclass.prototype = Object.create(superclass)
> Object.defineProperty(subclass.prototype, 'constructor', { value: subclass })
> subclass.prototype.method = function() { 
>    //...
> }

Yes, this is the heart of the matter. Not freezing, not shallow vs. deep property copying (where deep must deal with closures at least).

> Object.extend used in my gist is BTW same as backbone's .extend

Ok, good to know. (Jashkenas, you didn't propose it!)

> and is just a shortcut of the code above:
> var subclass = superclass.extend({
>    initialize: function() {
>       // init ...
>    },
>    method: function() {
>       // ….
>    }
> })
> What I'm asking for is a standard function, no matter weather it's `Object.extend` or something else that makes it simple to do subclassing.

Allen has been trying to make it be a combo of <| and .{. Agree there could be a method, say Object.subclass (what a concept!).

> Also lisper in me thinks that `Object.extend` method is better than dedicated class syntax cause it keeps language concise.

Sorry, JS isn't LISP.

> In addition I think that if `Object.extend` will turn out to be broken it will be easier (not to say easy) to fix (`Object.extend = … `) then fixing `class Foo extends Bar`.

It would be about as hard either way.


> Regards
> --
> Irakli Gozalishvili
> Web:
> Address: 29 Rue Saint-Georges, 75009 Paris, France
> On Sunday, 2011-11-13 at 13:21 , Brendan Eich wrote:
>> On Nov 13, 2011, at 11:28 AM, John J Barton wrote:
>>> On Sun, Nov 13, 2011 at 9:34 AM, Brendan Eich <brendan at> wrote:
>>>> On Nov 13, 2011, at 9:30 AM, Brendan Eich wrote:
>>>>> The hard cases include:
>>>>> 1. Closures.
>>>>> 2. Proxies.
>>>>> 3. Private names.
>>>>> 4. Internal hidden state.
>>>>> 5. Side-table entries mapped to the object's identity.
>>>> In the case of objects implemented by C++ or whatever the host implementation language might be, the internal or side-table state may not even be representable in JS, even in strings (do not want raw pointers, or machine addresses however obfuscated, to leak to an attacker).
>>> I think we are on the wrong path here. I guess we followed: a standard
>>> extend() needs a copy-ish operation; a copyish operation is like
>>> cloning; cloning is hard; OMG.
>> That's not what happened. Some people are happy with shallow copy of properties available to ES5 reflection, or even a for-in loop. Others (Rick?) want deep, at least as an option. Deep could skip any private/internal/etc. properties, for sure. But deep tends to get into trouble because if you don't stay shallow, you run immediately into item 1: Closures. How would those be deeply copied, including their lexical environments?
>>> But let's back up. We are looking for one or a few operations such that:
>>> var a = op(b,c,d,...);
>>> creates a useful result when we use |a| and we are using existing JS
>>> libraries for guidance. By definition there are no show stoppers here.
>> I agree, other than inability to agree on what to standardize.
>>> We are creating new objects from existing objects using operations
>>> available to JS devs, but in standard and recommended way. The only
>>> two things can stop us from being successful: irreconcilable
>>> differences and inertia.
>> Ok, but this is all meta-pep-talk. What should the reconcilable standard be?
>> /be
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at

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

More information about the es-discuss mailing list