Re: 'table' as fallback for tables

[Tim Hill <drtimhill@...>]

> On Jun 26, 2016, at 12:59 PM, Philipp Janda <siffiejoe@gmx.net> wrote:
> 
> 
> I wouldn't use a default size. We'd lose the ability to check for non-array tables.

So perhaps #t == nil  for new tables? That way #t == 0 means an empty array.

> 
>> so #t returns 5, and obeys __len metamthods (so there is no ugly “.n”, just the built-in # operator and a yet-to-be-determined way to set the size).
> 
> I think the `#t = 3` syntax is still available, but where would you _store_ the size? Somewhere in the C struct making *all* tables bigger? Also, what should happen if you try to copy a table via `pairs()`? So far I like `.n` better.

I really don’t think a single 64-bit integer is such a huge hit on a table .. it’s certainly more compact than an “n” field though of course *every* table takes the integer hit. Though I agree if the size is “in-band” then it gets copied as a side-effect, which is nice. However, “first class” to me really means this:

— Every table has a size value (#t), which may be nil meaning no array. This can be read and written.
— Reading the size (writing???) respects metamethods.
— The C API lua_len() (or a replacement) can get/set size and also respects metamethods.

> 
> I agree. Most of it could be realized via a library without support from the Lua core ...
> 

The trouble is the “most” bit .. lack of metamethods is troublesome, though you can do some of that with __newindex and hiding the real .n in another table (messy) .. but at this point it’s all getting very complex again, which kinda defeats the purpose.

—Tim