Re: Lua 5.2 Length Operator and tables (bug?)

[steve donovan <steve.j.donovan@...>]

On Mon, Apr 23, 2012 at 3:56 PM, Javier Guerra Giraldez
<javier@guerrag.com> wrote:
> for starters, a programming language is supposed to make the human
> side do some work.

Quite so!  The discussion has been about the rather slippery nature of
Lua tables; which are 'quantum' data structures; they are neither
arrays nor hashes, although they have corresponding 'classical'
limits.

So, if you want a completely predictable array object, you have to
organize it. For example, this is a safe array:

https://gist.github.com/759589

This is the Lua 5.1 and wraps the array in a newproxy userdatum, so it
isn't possible to mess with it using the table.* functions.

The equivalent Lua 5.2 would use __len and be more efficient, but we
would still have the possibility of random modification with
table.insert, etc. One approach (if you are the system boss) is to
monkey-patch such table functions so they will operate correctly on
array-like tables. Or patch these functions directly so that they only
work on tables marked as being arrays.[1]

In short, by never using raw tables and only having tables with the
appropriate metatables, you can get the assurances you need, at some
run-time cost.

The rest can be done by a set of house rules, like 'no mixed mode
table constructors', which can be enforced by tools.

steve d.

[1] which is not a mad suggestion, if you are the system designer.