Nov 17 meeting notes

Brendan Eich brendan at
Fri Nov 18 09:03:27 PST 2011

On Nov 18, 2011, at 7:15 AM, David Bruant wrote:

> Subarray having a 'from' method sounds like a good idea, but it
> inheriting it from Array sounds counter-intuitive, because Array is
> indeed more of a placeholder than anything else. Very much like
> Object.getOwnPropertyDescriptor.

It depends. I really put the "Java" in "JavaScript" by not making a Smalltalk-like metaclass hierarchy parallel to the instance hierarchy. However, people using JS (directly and via languages such as CoffeeScript) *do* simulate class-side inheritance, either by copying or via __proto__ hacks.

Some (at least MarkM) on TC39 think class-side is _malum in se_ and so should be _malum prohibitum. Others (Allen would be a good exponent, veteran Smalltalker that he is) are in favor.

Dave pointed out how (see in particular) uses parallel constructor-side (and constructor-generator side) delegation to good effect.

So we have an open issue. Principled discussion of whether and how to heal the rift between the built-ins and user-defined constructors, what <| should do with function operands, etc. is welcome.

> If we had an operator dedicated to 2, there wouldn't be any
> Subarray.from method.
> Just for this email, i'll use <|| for 1 and <<| for 2 (for explanatory
> purposes, not as syntax proposition)

"Do both" is frowned upon if we can find consensus in favor of one way. Allen's point IIUC in making superFunc <| function (...) {...} wire up the function expression's .prototype to delegate to superFunc.prototype is that not doing that, while making the resulting function delegate to superFunc, does something even less common (unheard of), choice 3 in this list:

1. No class-side inheritance.
2. Class-side inheritance, meaning that if D <| C for constructors D and C, then D.prototype <| C.prototype (using <| freely here for [[Prototype]] linkage).
3. Constructor-side but not parallel prototype-side delegation.

Is there any known code (JS library, one-off app, even a non-counterexample gist) that chooses 3?

>> Direct Proxies slide show.
>> (...)
>> Attach:
>> (...) A number of us want
>> value observers and feel that proxies are less useful without them.
> What is wrong with a separate API like
> ?

Nothing except (a) misnamed wiki page :-P; (b) late (day-before) arrival for; (c) separate *and different*. (c) is the big one. If we can subset direct proxies that can attach or startTrapping, that seems better than disjoint intercession APIs, one stratified, the other unstratified *and unrelated* in signature, trap semantics, etc.

>> Consensus: Direct proxies (other than startTrapping/attach) accepted
>> for to replace older proxies proposals and strawmen.
> Great!

Yes indeed.


More information about the es-discuss mailing list