Re: Project lead nominations for standard libraries?

[Axel Kittenberger <axkibe@...>]

I think next to Luiz argument, you cannot do much operations with
number of keys, the biggest down I see on number of keys is when you
have a list in a table together with some string keys. Or other non
integer keys. In that case, we still want # to be the size of the list
or?

I'd like to have some response on the proposal above, move current #
implementation into something like table.apex() and have # just call
meta __len, and if there is no meta __len error. Then its up to some
minimal basic lib to provide __len.

I think it would be very Lua-ish, since then everyone can make his or
her # s/he wants and with it there is a huge pitfall less for new
coders.

On Sat, Jan 1, 2011 at 10:31 PM, joao lobato <btnfdp.lobato@gmail.com> wrote:
> On 1/1/11, David J. Slate <dslate@speakeasy.net> wrote:
>> When I first saw how the '#' operator applied to tables, it seemed a
>> bit of an anomaly.  In a language as elegant as Lua, I expected a
>> single-character core operator like '#' to have a simple, general, and
>> intuitively predictable meaning when applied to the data types for
>> which it's relevant.  As applied to strings it does, returning
>> unambiguously the length of the string.  But applied to tables, it
>> produces a sensible result only for arrays or lists with integer
>> indices beginning with 1 and without "holes".  Intuitively, I would
>> have expected a "length operator" as applied to an associative table
>> to produce a count of its keys, regardless of what kind of table it
>> was.  There could of course be an appropriately-named function that
>> worked like '#' actually does.
>
> +1
>
> Yes, a count of keys would be reasonable, O(1), and if one had been
> careful with his tables, would accidentally coincide with #'s current
> semantics
>
>