 |
lua-l archive |
|
|
||
|
Dirk Laurie wrote:
The hard thing to explain is that a table can be an array, a dictionary (useful Python term) or both. And that in the above example b[5] belongs to the dictionary part, not the array part of a. Once you have got that across to your newbie, the behaviour of # is not hard to explain. It is in fact a useful way of putting one's finger on the distinction.
I agree. I had some troubles at first with that when I approached Lua, but now I wouldn't want to go back! Maybe the problem (for me, at least) is that tables are perceived (by newbies) as a rather high level data structure, and in fact, compared with the basic data structures of other languages, they really are!
But actually they are fairly low-level, in Lua terms. That is, they are not meant to be as an highly abstracted thing (the hash vs. array part issue leaks everywhere, although Lua team "pretends" ;-) it's an implementation detail :-) ).
So maybe it would be useful to point out to newbies that, although tables afford powerful capabilities to the programmer, they are neither a "pure" array, nor a "Java Map" nor a "Java Set" nor a "C++ array_list" or whatever!
If you need that level of encapsulation, specialization and data hiding, then you should write extra code on top of tables to achieve that level of abstraction.
Although I discovered (with time :-) ) that you seldom need such an infrastructure. If you stick to good programming practices and keep your code readable an linear, you often can get by with tables as they are, possibly using a thin object model (say, some convenience metamethods).
I agree that there are many applications in which the cardinality of a table is a necessary concept, but please don't change the meaningof the hash. Backward-incompatible changes that cause existing programs to break are only allowable if truly unavoidable. Better have a function with a another name (table.size?) for the actualnumber of objects in a table.
Yes, definitely. I wouldn't welcome such a change of semantics, especially because it wouldn't fit all use cases. As for naming, table.size would still be a bit unclear. I would prefer something more explicit still (say, table.nofentries or table.nofkvpairs, notwithstanding their ugliness, or something alike).
Dirk
-- Lorenzo