Re: table library changes (was Re: table.new in 5.3?)

[Philipp Janda <siffiejoe@...>]

Am 28.11.2013 00:38 schröbte Rena:
> I don't think passing an iterator instead of an array is suitable 100% of
> the time (sometimes you need to access arbitrary elements at random),

Certainly not.

> Again I find myself often wishing for an is_indexable() and is_callable()
> so that I could just accept any object (table, function, userdata) and not
> have to explicitly check types. I'm a big fan of duck typing.

Me too. But I don't miss `is_callable()` or `is_indexable()` any more: 
It is not much trouble to wrap a functable or a callable userdata in a 
closure to pass it to a function checking for a function argument, and 
you can pretty much assume that any table and any userdata (with a 
metatable) is indexable, but even if you know that a value has an 
`__index` metamethod, it could still raise an error for some (or even 
all) keys, so `is_indexable()` doesn't help much. (Technically strings 
are indexable as well, but you probably don't want to count those).

> I'd also been bitten before by the C API not accepting a table with
> a __tostring metamethod as a string. (Was that changed in 5.2?)

No, but `string.format` calls tostring for arguments to `%s` and there 
is `luaL_tostring` which respects `__tostring` as well.

> btw, I very much like the idea of moving most "table" functions to an
> "array" library (not "list" because that brings linked lists to mind) and
> making some distinction between the two. Treat "array" as a special case of
> "table" - a table in which all integer elements range from 1 to n with no
> gaps. (Or from 1 to self.n with possible gaps?)

The question is: What would be in the new table library? As long as we 
don't have some functions to put there, I don't see a reason to rename 
the current table library to array.

Philipp