[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: table library changes (was Re: table.new in 5.3?)
- From: Philipp Janda <siffiejoe@...>
- Date: Thu, 28 Nov 2013 02:42:04 +0100
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),
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.