Re: Standard libraries (was Re: Virgin tables)

[Mark Hamburg <mark@...>]

On Dec 30, 2010, at 12:17 PM, HyperHacker wrote:

> I quite like the proposed array interface (and might end up just
> implementing it in a library of my own), though array(...) somewhat
> irks me - wouldn't array{...} be much more efficient in most cases?
> You might provide a check (which can be toggled by something like
> array.debug.ValidateInput = true if performance is a concern) that the
> table can be used as an array (no holes or non-numeric args).
> 
> Of course, one great thing about Lua is that it could support both by
> checking if the first parameter is a table... unless of course you
> wanted to construct an array of tables. (Maybe if first param is table
> and no additional params?)

I thought about taking a table instead of varargs and opted for varargs because:

* It avoids worrying about needing a table that hasn't been modified elsewhere.

* It avoids worrying about tables that don't look like arrays.

* It makes the length well-defined even in the presence of holes -- e.g., it works with varargs as array( ... ) in a way that array{ ... } would not.

* It makes it easy to create arrays of objects (which are often going to be made of tables).

* The cost didn't seem to be that high -- either the client creates the table or the library does and I didn't have an example in mind for where the client would be likely to carry around a table for a while and then want to turn it into an array.

Mark