Re: '__iter', yet again!

[Javier Guerra <javier@...>]

On Wed, Dec 16, 2009 at 12:38 PM, John Hind <john.hind@zen.co.uk> wrote:
> Whereas '__iter' would be taking this historical evolution to its logical
> conclusion!

only if your objects can have one and only one conceivable iteration.
even now, tables have two: pairs() and ipairs().  currently, i find
far more readable to simply set iteration methods to any object that
can 'contain' other objects.

for c in dialog:controls() do..... end
for f in dialog:fields() do .... end

for c in server:clients() do .... end
for s in server:sockets() do .... end

for r in query:records() do .... end
for f in query:fields() do .... end
for fn in query:fieldnames() do .... end

> Generic For undoubtedly was a significant complication of the language, much
> more significant than "__iter" would be.
>
> But I would be interested to understand the reasoning behind implementing
> Generic For as it seems to be subject to the same criticisms you are now
> levelling at "__iter" - the old way was simpler and required no language
> innovations, so why was it deprecated?

innovations respect to what?

and no, it wasn't any simpler, since it had a specific meaning for a
special case.  Of course, it's the most common case, but it's really
'non-Lua' to bend the language minimalism just to make common cases
easier.  (that's what makes Python so practical, and so ugly in my
eyes)

 the current way is far more 'primitive' and minimalistic in the Lua way.

> I am in two minds between table.foreach and Generic For with __iter, but I
> find Generic For without __iter to be a rather half-assed implementation!

that only shows a limited point of view.

-- 
Javier