Make .data() binding work with iterable protocol

[bsidhom]

The current data binding implementation relies on random array-style access, but only ever accesses data sequentially. Some data structures (such as linked lists) cannot easily expose random access. Moreover, since this specifically uses bracket indexing, it only accepts Arrays or first-class array-like objects. Making a custom data structure indexable this way requires either an expensive Proxy (indexes have to be round-tripped from integers to strings on every access) or else requires the custom class to add explicit integer properties for each contained item; this adds memory bloat linear in the size of the data structure itself and also requires unnecessary bookkeeping.

If random access were required, it might be reasonable to require some cheaply-implemented but customizable accessor method (see, for example Array.at()). However, since this is not the case, it makes more sense to instead only require that input data types be iterable. This opens up efficient implementations for structures such as singly-linked lists and other purely applicative structures. Backward compatibility can be maintained by adding a cheap wrapper to implement iteration in terms of sequential indexing.

[bsidhom]

Note that this is just a sketch of the suggested functionality. I have not added the shim required to make this backward compatible with code that implements random bracketed access but is not iterable.

There's another question as to whether .data() should also require a .length method or whether it's sufficient to compute that dynamically during iteration. As far as I can tell, this is essentially used as a proxy to infer whether we're dealing with an array-like object. Ideally, this method would only check for the Symbol.iterator property and use that for iteration; sadly, that breaks compatibility.

[curran]

I'm curious, what limitation of Arrays are you facing?

Is there something wrong with converting the data to an Array first?