On Fri, Nov 11, 2011 at 1:22 PM, Allen Wirfs-Brock
<al...@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
