Re: '__iter', yet again!

[Jerome Vuarand <jerome.vuarand@...>]

2009/12/16 John Hind <john.hind@zen.co.uk>:
> This argument would have some merit if Lua did not already have the "generic for", which is strictly unnecessary as well! My argument is that if you are going to do something at all, you should do it consistently, thoroughly and elegantly. Once you have "generic for" you implicitly have the concept of "objects which can be iterated" and you have to have a way of defining how. Defining how an object should be iterated is conceptually the same as defining how it should be added or concatenated which is done in Lua with metamethods.

That's not true, we don't have a concept of "objects which can be
iterated", we have a concept of iterator functions (next), and
iterator factories (pairs). This is completely different, and you are
wrongfully introducing object oriented concepts in a language that is
not OO.

> Just the straightforward meaning of the keywords is violated by the current system - the notion of objects being "in" a function of another object makes no sense. In straightforward language, objects are 'in' other objects , not 'in' functions!

The keyword works if you use the principle of iterator factory that is
promoted in the standard library. Lua no longer supports "for k,v in t
do", now you have to write "for k,v in pairs(t) do", which you can
read "for key-comma-value in pairs of table t do". Lua let you use the
"object:factory()" syntax instead of "factory(object)", or even merely
"object" with __call. But the point is that the Lua generic for loop
only need a first class function, not an object with some interface.