Re: [Proposal] ## operator

[Tim Hill <drtimhill@...>]

> On Nov 21, 2014, at 9:02 AM, Axel Kittenberger <axkibe@gmail.com> wrote:
> 
> You're knowledge about other peoples fields and the issues they are regulary facing?
> 
> Anyway, I agree such operator is not a good idea, simply because the count isn't stored in the core. If it would, I'd say instead by all means make that integer accessible to the script, no big harm.
> 
> However, the resoning ought to be, what is a strong concept and well doable with the current code base without bloating it? In this case it is not.
> 
> Not, "I don't need that in my field of work, so I just suppose other don't as well." Or do you have a scientific method on operationalising how often other people need this or that with their way of using Lua?
> 

From previous discussions the argument goes (I think) like this: The table implementation does NOT currently store the number of keys. Modifying it to do so is of course possible, but it’s a little more complex than might at first appear (you have to handle things like placing a nil in the “array" part or over-writing a nil in the array part for example).

Such code in the table implementation, even with all the wrinkles, would undoubtedly be faster than anything that can be coded in Lua by a wide margin. HOWEVER, this code overhead is incurred for EVERY table in EVERY program all the time. When viewed this way, any savings you make for the very occasional instance when you need the key count of a table is overwhelmed by the overhead of doing all those useless counts on all the other tables; even by programs that NEVER get a key count anywhere.

This, as I understand it, is also the rationale behind the current # operator for tables; the operator itself is (relatively) slow since it computes array size on a just-in-time basis, but this slowness is preferable to always tracking the sequence size pro-actively since in many cases this information is never needed.

—Tim