On Fri, Nov 11, 2011 at 1:22 PM, Allen Wirfs-Brock
<allen@wirfs-brock.com> wrote:
> However, if you want the object to be mutable and to act like a real array, then it has to have the array specialness. Â The specialness comes, not from the [[Class]] property but from its alternative definitions of [[DefineOwnProperty]] (see ES5.1 spec. 15.4.5.1).
The Array-like thing discussed in this thread is going to be mutable.
> In ES.next a JS programmer will be able to easily define such an object. Â But for ES5 it takes special implementation level intervention. Â Â Since this capability is going to ultimately be in ES.next I don't see why you couldn't do it now, assuming the the engine implementors are all willing to cooperate.
>
> Basically, you would specify that the [[Prototype]] of the instances inherits from Array.prototype and that the instances use the [[DefineOwnProperty]] specification from ES5 section 15.4.5.1.
>
> In either case, you would be specifying a new kind of ES "native object" rather than a "host object'.
>
> BTW, I think that either the immutable or mutable approach would work. Â However, since the collection is not "live" I don't see why you would really care whether or not a client mutated it. Â If they want to process it by deleting elements after they are examined, so what?
Exactly, this is why I'm proposing that it should be mutable.
This does still leave the problem of making Array.filter(myNodeArray,
function(el) { ... }) "work" though. I.e. I think we'd like it to
return a NodeArray rather than a plain Array.
More importantly, we want myNodeArray.filter(function(el){ ... }) to
return a NodeArray. This would be doable by putting a special version
of filter on NodeArray.prototype which would shadow
Array.prototype.filter. This would make myNodeArray.filter "work", but
not Array.filter.
I'm happy to start a separate thread on es-discuss about this, but I'm
worried that it'll fragment the current thread.
/ Jonas