array like objects

Jorge Chamorro jorge at
Tue Dec 15 08:46:16 PST 2009

On 15/12/2009, at 16:21, Brendan Eich wrote:
> On Dec 15, 2009, at 5:05 AM, Jorge Chamorro wrote:
>> On 15/12/2009, at 13:51, P T Withington wrote:
>>> (...)
>>> I once had the vain hope that I could say:
>>> function MyArray () {}
>>> MyArray.prototype = [];
>>> to create my own subclasses of Array.  That might have lessened the need for isArrayLike.
>> For that, we'd need an Array.create(). It might be a good thing... ¿?
> What would Array.create do?

Array.create(prototypeObject) would return an [] instance whose prototype chain's first object is prototypeObject. 

Currently, afaics, there's no way to do that (subclassing Array) not without resorting to .__proto__ or manually extending instances via own properties/methods.

It's the same functionality provided by Object.create(), but for [] instead of {}.

> Tucker is looking for a way to compose custom [[Put]] with prototype-based delegation. My reply suggested that if [[Put]] were a property name, just like "length", and looked up along the prototype chain, so that the default [[Put]] was in Object.prototype, the custom Array [[Put]] that updates .length to be one greater than the highest index were on Array.prototype (or on [] in Tucker's example, but in general on the class prototype would suffice), etc., then we would not need anything new like Array.create.

The way I see it, the subclass' prototype object ought to come -necessarily- before the Array.prototype object in the subclassed instance's prototype chain. If not, every other existing and future [] instances would be affected too. Also, because if not there would be no way to create two different [] subclasses.

If for some reason you wanted/needed to override/shadow any/some of Array.prototype's methods, isn't it that, in order to achieve that, the subclass' prototype object ought to come before the Array.prototype object in the instance's prototype chain ? That, or manually extending each and every instance with own properties ?

AFAICS, anything that comes -in the prototype chain- after Array.prototype would extend all the [] instances at once. But most likely I'm missing something...

> We would have one mechanism, prototype-based delegation, for finding methods (internal or external), and a complementary private-name scheme for generating and (implicitly, in the case of certain private names built into the language) using names that can't be expressed outside of an abstraction or module boundary.
> That still seems winning to me, but I didn't implement anything like it in 1995. It may have come up in ES1 days (I have vague memories), but no one implemented it so it was a dark horse for standardization.

Hmm. sorry, I don't quite follow.


More information about the es-discuss mailing list