 |
lua-l archive |
|
|
||
|
Am 28.06.2013 20:11 schröbte Tim Hill:
On Jun 28, 2013, at 5:18 AM, Philipp Janda <siffiejoe@gmx.net> wrote:Why do you care if it's an "array"? No matter what, you can access the values for the integer keys from 1 to n. If nil is not allowed as a value, Lua gives you a fast way to calculate that n. If nil may be in there somewhere, somebody better tell you where this table is supposed to end because that information is not obvious!Yes, it's NOT obvious. It could be MADE obvious by using "empty" instead of nil, in which case the "fast way to calculate n" would be MORE useful, which seems to me a good thing, doesn't it? Are you saying it's a bad idea to make arrays more useable?
No one is arguing that sentinel values cannot be useful. Using a sentinel value in arrays with holes let's you use `#` and `ipairs` (which you also can do using a metatable and an explict length field). Lua already can do everything your proposed "empty" type would do. Why do you want to force everyone to use the same sentinel value?
Btw., one sentinel is not always enough[1], and sentinel values are not appropriate for every sparse array (e.g. some numerical algorithms for solving differential equations generate large sparse matrices where only the elements near the diagonal are nonzero).
[1]: https://github.com/siffiejoe/lua-multikey/blob/master/src/multikey.lua#L10
Is it better to have 20 different workarounds to a common problem than one simple, clear, language supported fix?
If you want arrays with holes, there are basically only three different workarounds:
1. use nil for the holes
pro: - saves memory for very sparse arrays
- fits well with varargs and table.(un)pack.
- no mapping from hole to nil required
con: - needs explicit length field
- needs metatable if you want `#` and `ipairs` to work
2. use a sentinel value for holes
pro: - can use `#` and `ipairs` without metatable magic
con: - cannot handle large sparse arrays
- does not mix well with {...} and table.pack( ... )
3. use some specialized container class/object
pro: - can't be mistaken for a raw table
- can implement whatever policy you see fit
con: - does not feel like a raw table
First: Arrays with holes are rare, and 1) already handles (all of) them
pretty well (with the exception of automatically calculated array
length), so much attention in terms of language features is probably a
waste of effort.
If you look for a general, "standard" (as in: used in Lua's standard
library) way, go for 1). You probably should use "n" for the array
length. If you cannot live with the slight inconvenience of handling the
array length yourself, go for 2). But even with a standardized "empty"
type/value, 2) will not make 1) obsolete. And it will not make other
sentinel values obsolete either.
Adding a type to the language is a big deal (much bigger than e.g. a library function), and it would affect a lot of code ...
--Tim
Philipp