> On Wed, Jun 24, 2009 at 14:36, Luiz Henrique de
> Figueiredo<
lhf@tecgraf.puc-rio.br> wrote:
> >> Given the persistent confusion about arrays vs. tables, and the
> scope
> >> for really nasty hard-to-find bugs if people get it wrong, it might
> be
> >> worth considering a 'strict mode' option (by default off, of course)
> >> that cause #, table.remove/insert etc to *fail* if you give them a
> table
> >> that's not an array. By fail, I mean throw an error to cause you
> >> application to stop.
> >
> > How do you propose to do that? I mean, how can the Lua core detect
> that a
> > table is not an array without traversing it completely?
> >
>
> That's easy, just flag the table on each modification and then just
> read the flag, that shouldn't produce much overhead, and would even
> help making some optimizations (like allocating the map part
> differently from the array part, etc.).
>
> This would settle the matter straight about what a table is and how it
> behaves at any point at runtime, but more importantly, in the manual
> (eg. more meaningful definitions for #).
>
> This leads to a chain of changes:
>
> 1) make a subtype() built-in function to read that flag (it would give
> you "array", "sparse array", "map", etc.).. let type() alone for
> compatibility.
> 2) throw an error when applying # to any table that's not subtype
> "array" -- very much needed for reliability of programs in general,
> IMHO.
> 3) allow appending with a[] = x instead of a[#a + 1] = x, to allow
> change 2).
>
> You might argue that these features are not core enough to worth
> bloating the language with, especially since you can do them in plain
> lua or C, but I can argue that the problems with that approach are
> even bigger: 1) didactic (new users), 2) standardization, 3)
> efficiency. A standard library of common abstractions would solve all
> problems of course, but I is it possible to build it efficiently
> (either in C or lua) on top of current infrastructure?
