lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Am 24.11.2013 14:12 schröbte John Hind:
Dirk and I had a serious go at worrying at the table library a few months back and here is what I came away from that experience with (aside from the bruises which have not yet completely healed!)

1. The current table library is not a table library, it is a list library. But there is a lot of stuff in the basic functions that ought to be moved to a table library (or retired).

I'd call it array library because I associate the term "list" with single- or double-linked lists. But then there aren't that many essential non-array functions on tables ... I'd be ok with `raw{g,s}et` and `next` moving to the table library (or even the debug library), but e.g. `pairs` and `ipairs` certainly belong to the base library, IMHO.

2. 'ipairs' and its associated metamethod are redundant - just use the numeric form of 'for'. This realisation suggests a re-evaluation of the approach in my "Self-iterating Objects" powerpatch.

I disagree. The numeric for loop is a second class citizen: you can't pass it to (or return it from) a function (which sadly is still not being done very often in the Lua code I've seen -- the recently released lua-fun being a notable exception). Whenever you pass a table as input to a function, consider passing an iterator triplet instead. This way you can use the function for `pairs()`, `ipairs()`, `filter(p ,pairs())`, map(f, ipairs())`, and possibly other data sources. At some point in the future I'd like to see a merge of iterators and LTN12 sources and sinks. The only reason for the continued existence of "numeric for" is its superior performance compared to a `range` iterator function.

4. Everything except 'sort' can be done (almost) as efficiently (and to taste) in Lua. It would be useful to have 'sort' surfaced in the C API as well as a Lua library function.

What makes `table.sort` different? Certainly you can implement an efficient sort routine in Lua (and it has been done before[1]). I'd say `table.unpack` and maybe `table.concat` are the only functions in the table library deserving a C implementation.


My approach is to remove everything except 'sort' from the 'C' table
library and use my own Lua implementation with an OO approach to
wrapping table as Table, List and Set classes. But it still bothers
me that the current metamethod design does not allow me to intercept
assignments that would break the objects (changing an existing List
value other than # to nil, assigning other than 'true' or 'nil' to an
existing Set member.)

You can solve that using proxy tables. I've been toying with the idea of using different "views" on a table. A "set" view (proxy table) would translate values to boolean on __index (`true`/`nil` on `__newindex`), return only trueish values via __pairs, and raise errors for operations that don't make sense for a set. Of course `ipairs()` and its metamethod are used to implement the "array" views (which of course also intercept the invalid assignments you describe). A single table could be the backend for multiple different views, and the type of view you use for access determines which operations are valid and how the values are translated between view and backend table.