Re: toArray() method for array-like DOM list objects

23.12.2011, 03:07, "Boris Zbarsky" <bzbarsky@MIT.EDU>:
> I do think that if I were
> implementing toArray in Gecko, I would be likely to just reuse some of
> the slice() code.

It'd be OK to temporarily use toArray() as wrapper for Array.prototype.slice.call() _initially_. But then implementation could be improved internally while already having convenient and intuitive external toArray() API.

>> šCould you provide an example of such object where slice() works, but toArray() would not?
>
> Sure. šA JS array object.

It's very questionable why someone should want to convert Array to same Array. That would be just waste of computer power and should not be allowed anyway. By the way, that's what is the key difference between what Array.slice() is intended for and its workaround use for arrayLike-to-Array conversion. Calling Array.slice(0) is exactly as pointless as Array.toArray() would be.

> Or this object:
>    { length: 2, 0: "a", 1: "b" }

Result of calling Array.prototype.slice.call() for this object is unlikely to be desired:
[a,b]

Direct conversion to Array is probably just inapplicable here. If someone would want, then he would desire to have two separate methods like arrayKeys() and arrayValues() instead of just toArray().

>> šTheoretically _all_ array-like objects that currently can be converted to Array using Array.prototype.slice.call() should have toArray() method.
>
> "array-like" in this context means "has a property named 'length'".
>
>> šIt would be enough to have this ability for DOMNodeList and DOMTokenList only, though. I doubt that inability to call toArray() for literally _any_ object could be an issue in real-world usecases.
>
> It would mean that code which currently uses Array.prototype.slice and
> can take as input either arrays or nodelists (common in JS libraries)
> would need to either keep using Array.prototype.slice or check what its
> argument is.
>
>> šEach object type has its own API based on what's expected (and is documented on MDN in particular) from the specific objects, it's perfectly OK.
>
> I doubt you're really appreciate NodeList and HTMLCollection having
> different APIs, even if they were documented...

Oh, NodeList and HTMLCollection are actually nearly identical things from web-developers point. Both (in fact, all one-dimension DOM lists) should be Array-convertable, of course.

>> šPassing DOM list to Array constructor would probably be ambiguous since DOM list object itself can represent a single Array item
>
> This ambiguity already exists for numbers, yes? šWhy is a separate
> argument not needed there, apart from the "it's always been that way"
> argument.

What exact ambiguity do you mean as for numbers? Could you provide an example?

>> šWe could probably do something like Array.import(domList) instead, but it seams to be still questionable whether this would be really better than toArray() method applied directly to DOM list object itself.
>
> It would be better for cases when you're working with arbitrary
> arraylikes which may or may not be nodelists, for sure.

Well, I see. I'm talking about DOM here, though. The task of conversion to Array itself was born mainly (if not only) because DOM has its own (not so usuable in real world) Array analogues like DOMNodeList that however has no Array methods and is _live_ collection that is undesirable in some situations where non-self-altering DOM-list "snapshot" is needed.

By the way, didn't you consider having several ways to achieve same result? For example, we could have both domList.toArray() and Array.import() methods simultaneously. It's probably quite acceptable option and quite usual situation for programming languages in general.

Received on Thursday, 22 December 2011 23:57:45 UTC