>>>>> "Coda" == Coda Highland <chighland@gmail.com> writes:
>> why the _ipairs metamethod was deprecated?
Coda> Because there's no need for a metamethod for something as simple
Coda> as ipairs()
Some of us greatly disagree with this position - in particular, it
seriously impacts what you can do with userdatas.
For example, if embedding into an environment (e.g. a database) which
has a native array type (such as SQL arrays) which can be iterated
sequentially more efficiently than they can be indexed into (because
they have variable-length elements), it means that you can't just
provide an __ipairs and have everything just work in the obvious way;
instead, ipairs() will work inefficiently and you have to provide a new
but functionally identical method.
IIRC the whole reason that ipairs doesn't need a dedicated metamethod is because there's ALREADY a metamethod for it: __len. If "for i = 1, #ud" works then "for k, v in ipairs(ud)" ought to work, I thought.
/s/ Adam
Oh hold on, never mind. I understand a bit better now -- I misread what you had written, my apologies.
I disagree that it's functionally identical, though. It changes the state of the container, whereas ipairs() doesn't. I really see no reason to complain about "for k, v in result:rows()".
/s/ Adam
And I just realized I STILL hadn't read it right. You were talking about array data types within a single field.
Okay, I can see an argument for __ipairs there, but... IMO, it kinda makes more sense for the binding to convert it to a native Lua structure? Alternatively, it shouldn't be too difficult for the binding to special-case the indexing operation to be able to recognize iteration patterns, because there are more places than just ipairs() where that would make a difference.
/s/ Adam
