Re: question on ipairs

[Andrew Gierth <andrew@...>]

>>>>> "Coda" == Coda Highland <chighland@gmail.com> writes:

 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.

 Coda> IIRC the whole reason that ipairs doesn't need a dedicated
 Coda> metamethod is because there's ALREADY a metamethod for it: __len.
 Coda> If "for i = 1, #ud" works then "for k, v in ipairs(ud)" ought to
 Coda> work, I thought.

That doesn't address the issue I raised above at all.

An __ipairs metamethod dedicated to a specific userdata type has the
option of storing the "current index" in some fashion that respects the
underlying data structure. In 5.4 this doesn't work, and so when the
user does  "for k,v in ipairs(ud) ..."  then the userdata just sees an
unrelated series of calls to __index(ud,1), __index(ud,2), ... etc.

-- 
Andrew.