Re: 'table' as fallback for tables

[Coda Highland <chighland@...>]

On Tue, Jun 28, 2016 at 9:32 AM, steve donovan
<steve.j.donovan@gmail.com> wrote:
> On Tue, Jun 28, 2016 at 6:17 PM, Andrew Starks <andrew@starksfam.org> wrote:
>> First, `__len` is about sequences and this isn't a sequence. This
>> extra metatable is more about making `#(table.pack(...))` work as you
>> would *hope* (maybe naively expect, but you'd be wrong) and that is a
>> conspicuous amount of fanciness in such an austere language.
>
> A 'conspicuous amount of fanciness' is totally not the Lua spirit ;)
>
> I suspect we're starting to spin around an old familiar whirlpool by
> now.  It's hard for me to judge, since I like tables and know how to
> keep them being sequences.  But the 'horror of holes' definitely comes
> up with questions from newcomers. It's natural to expect that a table
> knows how _big_ it is.  The special restrictions of # would then
> appear confusing [0]

I find this particular whirlpool to be substantially more relevant
than many of the oft-rehashed debates on lua-l. The outcome doesn't
impact me PERSONALLY because I don't have any code that relies on the
behavior of nils in tables (I don't remember if I even use #t in my
code without going and looking; my use case doesn't even need linear
sequences because everything's a map), but I think that finding a
satisfying resolution to what is widely considered to be a wart would
be good for everyone.

> [0] In a similar vein, a colleague got burned by std::list.size() in
> C++ - he assumed it was O(1) but it was O(n)! [1]
> [1] fixed since C++11, thank the Goddess...

std::list always makes me cringe, because it's an extremely generic
doubly-linked list and is therefore only the correct tool for the job
in a limited set of scenarios. The fact that size() is O(n) on a
linked list is unsurprising from that perspective and the change in
C++11 is mildly annoying to me because most of the code I write that
wants a linked list doesn't care about maintaining a size value but is
using a linked list explicitly for performance reasons.

/s/ Adam