Minimalist (why) classes ?

[Brendan Eich]

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 mozilla.com> 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