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

[Rena <hyperhacker@...>]

On Tue, Apr 24, 2012 at 01:22, steve donovan <steve.j.donovan@gmail.com> wrote:
> 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.
>

I often felt there'd be a lot less confusion about the table library
if it were named 'array' instead.

-- 
Sent from my toaster.