Re: Lua next version

[Miles Bader <miles@...>]

bb <bblochl@arcor.de> writes:
> The problem is the provided possibility of generating  tables with
> holes. I do not see any indispensable advantage in making holes in
> arrays or lists or tables involuntary - is there any advantage?  I do not
> even see a real application for holes in any array or in any list, say
> in any table by intention.

One obvious case where holes are desired is when you're _not_ treating a
table as an array, but simply as a key-value mapping; when you happen to
add entries with integer keys, they may end up in the array part of the
table -- likely resulting in holes.  In such a case you wouldn't want
Lua to act differently than it does today (e.g., by signalling an error,
or "filling in" the holes or something).

Thus, given Lua's "transparent dual nature" tables, holes are necessary.

Anyway, if your application doesn't need holes, then don't make holes.
If your app has a bug so it makes holes inadvertently, then fix your app.

[You could ask for a "dedicated array" data type, but that would be a
fairly big change to Lua's intentionally very simple model, and it's not
at all clear that the result would be better.  You could also, of
course, make your own userdata array datatype, and that would suffice in
many cases.]

-Miles

-- 
Come now, if we were really planning to harm you, would we be waiting here,
 beside the path, in the very darkest part of the forest?