[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: 'table' as fallback for tables
- From: Tim Hill <drtimhill@...>
- Date: Sun, 26 Jun 2016 14:31:51 -0700
> On Jun 26, 2016, at 12:59 PM, Philipp Janda <email@example.com> 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.