From: Richard Cornford on
Dmitry A. Soshnikov wrote:
> On Oct 27, 4:00 pm, Richard Cornford wrote:
>> [...]
>> Good. That reduces your options to creating array instances and
>> assigning functions to their named properties to provide
>> additional method (and not using for-in loops on those object,
>> or filtering the for-in loops used so they don't act on the
>> added methods).
>> [...]
>
> And what's the main goal do not extend Array.prototype if you
> still avoid for-in loops for you single in-place extended
> objects?

The goal is not in the OP, just the requirement to avoid modifying
Array.prototype. There is still no need to avoid for-in on these new
objects, just the likelihood that the values will need to be filtered if
it is used on them. Then again it may be entirely feasible to avoid
for-in on these objects while leaving it available for ordinary Arrays.

> for-in loop is only useful for sparse arrays (better - very
> sparse arrays, with indexes: 0, 1, 99, 502) and for such
> structures better to use Object (without afraid for-in loops
> as no one in good sense will extend Object.prototype).

Yes, we have never known whether the use of for-in has any relevance for
this object at all. I just mentioned because its use is impacted by any
viable strategy adopted and it makes sense to be aware of that up-front.

Richard.

From: kangax on
Dmitry A. Soshnikov wrote:
> On Oct 28, 1:24 am, kangax <kan...(a)gmail.com> wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> kangax wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>>> kangax wrote:
>>>>>> Thomas 'PointedEars' Lahn wrote:
>>>>>>> kangax wrote:
>>>>>>>> I actually don't see why you would want to have method in proto chain
>>>>>>>> of an object instead of just assigning that method to an object
>>>>>>>> directly.
>>>>>>>> Latter one is simpler
>>>>>> [...]
>>>>>>>> and much more compatible.
>>>>>>> Only if you use __proto__.
>>>>>> How else can you assign to object's [[Prototype]]?
>>>>> In most cases, a standards-compliant reference to the object's prototype
>>>>> object is known; in this case, `Array.prototype'. In fact, I do not
>>>>> think there is much value in replacing the prototype object of Array
>>>>> instances with an object that has the original value of `Array.prototype'
>>>>> next in its prototype chain. The only advantage of this approach that I
>>>>> can think of is that properties inherited from Array.prototype could be
>>>>> shadowed without overwriting them.
>>>> Perhaps, you should read this thread again more carefully?
>>> Or perhaps you should?
>> Are you sure you haven't missed anything?
>>
>> "I would like to create own Object that would behave similar to Array
>> Object, but would have defined some methods that are not in current
>> ^^^^^^^^^^^^^^
>> Array implementation. It need to not touch .prototype of an Array, so it
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> should work like this"
>>
>
> But anyway, the wrapper you created has enumerable [.last] method.
> What's the main goal to afraid Array.prototype itself in this case if
> still for-in loops will affect on your wrapped object properties?

Well, I'm not the one asking for it, so I wouldn't know real intentions
;) Probably to avoid augmenting "public" Array, and so reducing
conflicts with 3rd party code.

>
>> Why wrong property? Doesn't `push` affect array object's `length`?
>>
>> [...]
>>
>
> [.push] can affect `length` property and without wrappers:
>
> var o = {
> push: [].push
> };
> o.push(1);
> o.length; // 1

You're right. Bad test on my part.

[...]
From: kangax on
Thomas 'PointedEars' Lahn wrote:
> kangax wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> kangax wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>>> kangax wrote:
>>>>>> Thomas 'PointedEars' Lahn wrote:
>>>>>>> kangax wrote:
>>>>>>>> I actually don't see why you would want to have method in proto
>>>>>>>> chain of an object instead of just assigning that method to an
>>>>>>>> object directly.
>>>>>>>>
>>>>>>>> Latter one is simpler
>>>>>> [...]
>>>>>>>> and much more compatible.
>>>>>>> Only if you use __proto__.
>>>>>> How else can you assign to object's [[Prototype]]?
>>>>> In most cases, a standards-compliant reference to the object's
>>>>> prototype
>>>>> object is known; in this case, `Array.prototype'. In fact, I do not
>>>>> think there is much value in replacing the prototype object of Array
>>>>> instances with an object that has the original value of
>>>>> `Array.prototype'
>>>>> next in its prototype chain. The only advantage of this approach that
>>>>> I can think of is that properties inherited from Array.prototype could
>>>>> be shadowed without overwriting them.
>>>> Perhaps, you should read this thread again more carefully?
>>> Or perhaps you should?
>> Are you sure you haven't missed anything?
>>
>> "I would like to create own Object that would behave similar to Array
>> Object, but would have defined some methods that are not in current
>> ^^^^^^^^^^^^^^
>> Array implementation. It need to not touch .prototype of an Array, so it
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> should work like this"
>
> So the thread has drifted a bit. Your approach touches ".prototype of an
> Array", too. That you are using `__proto__' to refer to said object
> instead, does not change that.

Doesn't OP example make it clear what was meant by "touches"? If I
understood it right, the snippet with __proto__ setting doesn't "touch"
`Array.prototype`.

>
>>> As I understand it, this thread is about creating an object that works
>>> like an Array instance but has additional features. Because the [[Put]]
>>> method of Array instances cannot be inherited (your push() tests the
>>> wrong property), that can only be accomplished with a true Array
>>> instance, and
>> Why wrong property? Doesn't `push` affect array object's `length`?
>
> It does, but the array-ness of an object referred to by `o' is defined by an
> assignment to o[i], with `i' being the equivalent to an unsigned 32-bit
> integer value, to change the value of o.length if o.length was previously
> smaller than i+1 (see ES3F, 15.4). Indeed, Array.prototype.push() is one of
> the "intentionally generic" methods, so it can work with any object that
> provides read access to a `length' property (see ES3F, 15.4.4.7.)

Thanks. You're absolutely right. Should have used property accessor instead.

--
kangax
From: Jorge on
On Oct 27, 11:03 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:
> kangax wrote:
> > Thomas 'PointedEars' Lahn wrote:
>
> >> In most cases, a standards-compliant reference to the object's prototype
> >> object is known; in this case, `Array.prototype'.  In fact, I do not
> >> think there is much value in replacing the prototype object of Array
> >> instances with an object that has the original value of `Array.prototype'
> >> next in its prototype chain.  The only advantage of this approach that I
> >> can think of is that properties inherited from Array.prototype could be
> >> shadowed without overwriting them.
>
> > Perhaps, you should read this thread again more carefully?
>
> Or perhaps you should?
>
> As I understand it, this thread is about creating an object that works like
> an Array instance but has additional features.  Because the [[Put]] method
> of Array instances cannot be inherited (your push() tests the wrong
> property), that can only be accomplished with a true Array instance, and
> there are two ways to provide it with new properties: a) augment the object
> itself; b) augment its prototype object so that those properties are
> inherited.  As for b), [].__proto__ === Array.prototype, so using the less
> compatible `__proto__' property is unnecessary.  (The same goes for user-
> defined objects, for which the prototype object can be referred to by either
> Object.prototype or usually UserDefinedConstructor.prototype.)  There is
> also little value in the extended prototype chain that you proposed as the
> method can easily be added to that Array prototype directly.  (It is all the
> same to for-in iteration.)

I order to create a "newClass" of [] you shouldn't augment
Array.prototype as that would automatically convert each and every
existing and future instance of [] into an instance of "newClass".

If you wanted to create two different classes of [], each with a
different .foo() method, augmenting Array.prototype would not work
either.

Augmenting Array.prototype would not work either if you wanted
"newClass" to override an existing Array.prototype method.

So, in order to leave existing instances as they are and be able to
create not one but as many different classes of [] as you wish, you
could either augment each individual instance manually which is what
Richard did, or attempt to use inheritance by inserting the class
prototype objects in the prototype chains of the class instances,
which is what kangax was doing, and I was wondering whether __proto__
is the only way to achieve it.
--
Jorge.
From: Dmitry A. Soshnikov on
On Oct 28, 2:12 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:

> [...]
> with `i' being the equivalent to an unsigned 32-bit
> integer value

Not an integer, but converted to string (as property names of any
object - only strings).