[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua 5.1 (work6) now available (for loop)
- From: Asko Kauppi <askok@...>
- Date: Thu, 19 May 2005 11:25:02 +0300
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
Can anyone point me to the discussion and rationale for this? I've
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
Perhaps I can do a better job explaining if I actually understood
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
but it should lead you to the right thread anyhow..) If there's a
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 <email@example.com>
Päiväys: 7. helmikuuta 2005 19.01.59 GMT+02:00
Vastaanottaja: Lua list <firstname.lastname@example.org>
Aihe: Vastaus: __pairs metamethod - is it in?
Vastaus: Lua list <email@example.com>
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
extra VM instruction (OP_TFORPREP) is needed for _every_ iterator
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
(alas, one side-effect is that _all_ tables are then callable
The other argument is that most containers do not have just a single
iterator. There are two standard iterators for plain tables and
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
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
BTW: The proxy-table problem is really orthogonal to the above
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
sugar for this. A function or method may solve this just as well