[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: 'table' as fallback for tables
- From: Tim Hill <drtimhill@...>
- Date: Sat, 25 Jun 2016 13:22:49 -0700
> On Jun 25, 2016, at 12:21 PM, Andrew Starks <andrew@starksfam.org> wrote:
>
> Wait. I think at first blush it may not be obvious why.
>
> This would be useful for schemes where it is okay to assume that the only way to manipulate the length was through the object, especially through __newindex.
>
> That may be too narrow of a use case and might encourage bad design. I could see that point of view.
>
> I'm undecided.
>
It’s an interesting idea, but I think it hints at something else … that Lua really needs an explicit first-class array length, not a # operator that kinda, sorta tells you length under certain ideal conditions.
Someone else noted here that whenever the “.n” convention is mentioned people get kinda awkward. I agree; the length of an array does seem to be something that should be more “baked-in” than a mere library convention. The # length has never seemed to me very first-class; it just tells you the result of running an algorithm which only gives meaningful results when the table is a valid sequence (with no way to check in O(1) time if the table is indeed a sequence).
Even Roberto’s comments on table.pack() and table.unpack() speak to this. Mostly when I teach people Lua they go “ooh that’s just so clean and simple” .. it just “clicks” with them. But then you have to explain that to access varargs you need to unpack them, and oh, when they are unpacked you can’t use #t because there might be a nil, and you have to use this “.n” thing, oh … but when you repack args table.unpack() doesn’t use it (even though pack creates it) .. and I see people’s eyes glaze over. It’s definitely not as “clean” as the rest of Lua imho.
Ignoring syntax and compatibility issues for a moment, what would you have if a table had an explicit, unambiguous, first-class array length?
— No confusion over the meaning/behavior of ipairs().
— # would always be meaningful for all tables.
— table.pack() and table.unpack() would mirror each other exactly.
— The awkward “.n” convention could be scrapped.
— Arrays could contain nil values.
— Lua could potentially use the declared length to optimize internal table structure.
— Far fewer posts here on people not understanding #, sequences, and ipairs().
Of course there are all sorts of issues; if an array has length 4 what does t[5] = 10 do? Should table.insert() automatically lengthen an array when appending? And others. But I really wonder if these issues are any worse than the current odd mix of sometimes using #, sometimes stopping at the first nil, and sometimes using “.n”.
—Tim
- References:
- 'table' as fallback for tables, Dirk Laurie
- Re: 'table' as fallback for tables, Philipp Janda
- Re: 'table' as fallback for tables, Roberto Ierusalimschy
- Re: 'table' as fallback for tables, Soni L.
- Re: 'table' as fallback for tables, Roberto Ierusalimschy
- Re: 'table' as fallback for tables, Soni L.
- Re: 'table' as fallback for tables, Dirk Laurie
- Re: 'table' as fallback for tables, Soni L.
- Re: 'table' as fallback for tables, Andrew Starks
- Re: 'table' as fallback for tables, Andrew Starks