lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Joshua Jensen kirjoitti 19.5.2005 kello 10.09:

which is due to the removal of the "for k in table" syntax.
Try "for c in next,mytable do"

BTW, I'm probably way late to the discussion, but the removal
of the "for k in table" syntax makes default table iteration
ugly.  (I actually didn't know about it...)  Just my rather
sad opinion...

Can anyone point me to the discussion and rationale for this? I've just
spent the past while searching the mailing list archives.  I must be
searching for the wrong keywords.

This really is concerning to me.  I tried to explain it to some people
today, and the immediate response was "What? Why? How does that help?" Perhaps I can do a better job explaining if I actually understood why adding
the extra (ugly) syntax for basic table iterations makes Lua a better

seems to be broken, so I'll put a copy here:

(note that this is just one message, and the "slow" was causing discussion. but it should lead you to the right thread anyhow..) If there's a '__pairs'
metamethod, you'd be able to revert to the old behaviour for tables, but
selectively choose the best (default) iterator for them.


Edelleenlähetetty viesti alkaa:

Lähettäjä: Mike Pall <>
Päiväys: 7. helmikuuta 2005 19.01.59 GMT+02:00
Vastaanottaja: Lua list <>
Aihe: Vastaus: __pairs metamethod - is it in?
Vastaus: Lua list <>


I think the real reason why 'for k,v in t' is deprecated is that it's
both ambiguous and slow. At compile time it is not clear whether t is
a table or a function. Therefore a (slow) runtime check in the form of an extra VM instruction (OP_TFORPREP) is needed for _every_ iterator loop.

And there's an implicit lookup of 'next' in the global table, too
(which is ugly from a VM design standpoint).

Whenever this compatibility check is gone, you can still write
'for k,v in obj' provided you add a __call metamethod to the table
(or userdata). Providing a default (implicit) __call metamethod for
plain tables may be an interesting way to solve the compatibility problem (alas, one side-effect is that _all_ tables are then callable objects, too).

The other argument is that most containers do not have just a single
iterator. There are two standard iterators for plain tables and more could
be conceived. And complex objects may provide dozens of iterators ...
So which one do you expect to be used when you write 'for i in obj'?
Which one do the readers of your code expect to be used?

Going with 'explicit is better than implicit', it's just good programming
practice to spell out _which_ iterator you want to use. Remember that
your code is much more often read than written. Therefore it is more
important to convey your intentions clearly than to save a few keystrokes.

BTW: The proxy-table problem is really orthogonal to the above problem.
You really want to be able to use the same 'way' to iterate over plain
tables and proxy tables. But this does not imply that we need syntactic sugar for this. A function or method may solve this just as well (as has
been shown).