RE: '__iter', yet again!

["John Hind" <john.hind@...>]

Oh come come!

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.

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!

-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br [mailto:lua-bounces@bazar2.conectiva.com.br] On Behalf Of Jerome Vuarand
Sent: 16 December 2009 14:04
To: Lua list
Subject: Re: '__iter', yet again!

2009/12/16 John Hind <john.hind@zen.co.uk>:
> I really cannot see why this solution is resisted – it is fully backward
> compatible and syntactically uncomplicated. The context of the explist is
> easily distinguishable being bracketed by the reserved words ‘in’ and ‘do’.

The beauty of the language, is that it has very few concepts, used in
many places. Rather than having a specific mechanism to iterate over
objects, the for loop use the mechanisms of multiple return values and
first class functions. The resistance comes from the fact that you
want to make Lua more complicated, just to save an explicit method
call. And that's assuming that the implicit __iter is better syntax
than an explicit method, which is arguable (e.g. I would disagree with
you). And concise and cryptic syntax overriding isn't even part of OO,
it's just often bundled with it.