I think all of the above examples are trying to create a case such as
| UInt32Array.from(nodelist, node => parseInt(node.value, 10) );
where neither can nodes be stored in an Uint32Array nor integers be
stored in a NodeList.
This might happen quite often, as `from` seems to be the "type casting"
operator ArrayA<X> -> ArrayB<Y> type - and if we cannot rely on implicit
casting, we need a X -> Y converter function.
A go-around to the "least common ancestor" array type that can store
both Xs and Ys is cumbersome. (And I'm not looking on performance, just
about clarity/conciseness).
> Since the next question will be: where is filter?
Good question. I guess however that since this does only concern the Y
type that the ArrayB can store, it would be built-into that ArrayB<Y>
constructor that we cast to.
E.g. typed arrays are known to clamp or take modulos of the passed
values; if you really wanted to completely omit passed values you'd
rather overwrite the `.from` method as a whole instead of relying on the
inherited one.
Bergi
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
