Design principles for extending ES object abstractions

Brendan Eich brendan at mozilla.com
Sun Jul 10 15:54:16 PDT 2011


On Jul 10, 2011, at 3:02 PM, David Herman wrote:

>>> I'm not sure what Array.prototype methods would or wouldn't work on instances of SubArray.
>> 
>> All of them.  They are all generic.
> 
> We're speaking too broadly here. It depends on what we want to work how. For example, .map can't magically know how to produce a SubArray as its result if that's how SubArray wants it to work. But what I'm actually more concerned about is the behavior of .length. Does the <| semantics make .length work automagically the way it does for ordinary Array instances?

Of course, since the thing on the right of <| is a newly minted Array which has its own length.

There's no issue here -- are you thinking of the other case (which I showed), Object.create([])? That's where length doesn't "inherit".


>> However, subarray instances have all the internal state and methods that make them true arrays so even if some of the inherited Array methods weren't generic they would still work.
> 
> Including .length (which isn't a method, but YKWIM)?

The <| operator sets [[Prototype]] in the newborn-because-literally-expressions right operand, to the value of the left operand. So (proto <| [1,2,3]) is an Array instance, no mystery or inheritance of Arrayness required. The trick as your SubArray example showed is not to lose the Array.prototype heritage -- proto ought to have Array.prototype on its proto-chain.

'length' is own in each Array instance, maintained by [[Put]] in ES1-3, [[DefineOwnProperty]] in ES5.

/be



More information about the es-discuss mailing list