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.
Cheers,
--
Jorge.
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
