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

23.12.2011, 05:33, "Boris Zbarsky" <bzbarsky@MIT.EDU>:
> On 12/22/11 6:57 PM, Marat Tanalin | tanalin.com wrote:
>
>> šIt's very questionable why someone should want to convert Array to same Array.
>
> Because they don't want to have to worry about whether the caller passed
> in the result of some jQuery operation or some DOM nodelist.
>
> I think you're assuming that the same person is writing the caller in
> both the caller and callee. šThis is generally a bad assumption in my
> experience.

Well, it's probably somewhat reasonable, indeed.

>> šThat would be just waste of computer power and should not be allowed anyway.
>
> Why the heck not?

It's just my opinion according to (as I believe) common sense. 

>> š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.
>
> It's not pointless at all: it make a copy of the input array, that you
> can then modify as desired without messing up the object the caller sees.

Actually, this is workaround use of slice() too: for making a copy of an array, we should have dedicated clone() method intended exactly to make Array copies and thus is more intuitive than slice() for this specific purpose.

>>> š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]
>
> Why is that unlikely to be desired? šThat's exactly the Array object
> that has the same behavior when iterated from 0 to length as the
> original array.

We have assotiative-array-like object with three items, but, after "converting" to Array, resulting Array contains two items. I think this is bad consequence of too much abstraction of Array-like definition based on length property existence.

>> šDirect conversion to Array is probably just inapplicable here.
>
> Why not?

Array is list thing while assotiative-array-like object is map. They're just not equivalent things that can be freely converted to each other lossless way.

>>> š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.
>
> Precisely. šBut how is [a, b] really different from { length: 2, 0: "a",
> 1: "b" } from a web-developer perspective?

We actually should compare DOM list with Array, not array with assotiative-array-like object. Generation of DOM lists is outside of web-developer control, that's why we need a convenient way to convert it to Array.

>>> š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?
>
> Sure. šWhat do you think
>
> šššnew Array(5)
>
> does? šHow does that compare to
>
> šššnew Array("x")
>
> ?

Never used such (new Array(5)) code. For Arrays, we have convenient different syntax that has more consistent and predictable behavior: [5].

>>> š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.
>
> But the DOM is not used in isolation. šYou're talking about converting
> DOM nodelists to arrays. šOnce you've done that, you have a mix of
> nodelists and arrays floating around; ideal APIs would not differentiate
> between the two.

Exactly. DOM lists as own DOM's Array analogue are quite evil. "Live" nature of DOM lists is very rarely (never?) used in real world. I would prefer to have native Array as result of any DOM functions like getElementsByTagName(), querySelectorAll(), etc. (by the way, querySelectorAll() is not even live, but all the same is still unusable non-native array). But since DOM is too isolated, it's authors have invented their own array type, and that's why we have current subject issue. Since DOM is guilty of this situation, then it's logical to expect the issue to be resolved on DOM itself side too.

>> š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.
>
> Having multiple APIs for the same thing is generally considered an
> antipattern, yes.

Well, maybe, but in real-world programming we often have multiple ways to do same things. For example, we have two jQuery methods .before() and .insertBefore() that effectively do same thing, but each one can provide more clear/intuitive code in different situations. This is usually called syntax sugar and is quite useful in practice.

Received on Friday, 23 December 2011 16:14:22 UTC