Re: [ANN] Lua 5.2.0 (work1) now available

[Klaus Ripke <paul-lua@...>]

On Thu, Jan 14, 2010 at 11:50:11PM -0500, Ted Unangst wrote:
> On Thu, Jan 14, 2010 at 8:07 PM, Doug Rogers
> <doug.rogers@elbitsystems-us.com> wrote:
> > Klaus Ripke wrote:
> >> I fail to see how breaking perfectly valid code
> >> by trading a well defined behaviour for all tables
> >> for something undefined on "arrays with holes" does any good.
> >
> > Agreed. The only reason #t has its undefined behavior is because it is
> > impractical for it to iterate the table. But the whole point of ipairs()
> > is to iterate the table - it is already doing that! So I prefer the
> > previous behavior - iterate until nil.
> 
> Being somewhat new to Lua, could someone explain a case where this
> really matters?
I frequently use a data type similar to a mime message
(for me it's more a MARC record with body):
ordered list of "headers",
separator (blank line),
more ordered stuff as "body".

> I'm having trouble thinking of a case where you would have a dense
> array part that you want to iterate on, but then "somewhere else" use
> int keys as a hash.  What would you do if the dense part grew?
Obviously I used to use nil as separator
and documented behaviour of ipairs to loop through headers.
Other int keys are not used as hash
and the dense part does not grow
- the mutable version of that datatype is a different beast.
Somewhat annoying to have to check all that code :-@


best