lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

I liked Diego's suggestion about table behaviour  changes being
controlled in a similar manner to weak keys and values.

For ME, I like Claim 1 and I do not want to support nils in tables.

I would like # to return the number of entries for contiguous arrays,
maxn for non-contiguous arrays
and return nil for tables with a hash part.


> =#{1,2,3}

> =#{1,2;[5]=5} -- currently undefined

> =#{a=1,b=2}

I could settle for also returning nil in the second case.
The idea is that if we cant supply a real value for # then return nil.

Re: the nils in tables, I think this can best be supported by userdata


Roberto wrote:
> I would like to make some claims...
> Claim 1: We lied: nils are not first-class values (because we cannot
> store them in talbes...).
> Claim 2: no magic will allow '#' to recognize nils at the "end" of
> a table. If we want lists with nils in the end, we not only need
> some 'n' field (that is, stored somewhere), but we also need some
> way to manipulate this field (t.n=t.n+1, table.setn, something like
> this). T[magic]=nil simply does not work.
> Claim 3: if we want lists with nils in the middle (holes), we better
> have lists with nils in the end. Too often we build lists adding
> elements one by one. To build a list with a nil in the middle, somewhere
> along the way it must have a nil in the end.
> So, changing the definition of '#' will not solve the problem of
> lists with nils.
> Lists with nils need a somewhat explicit notion of size. We can bury
> this 'n' deep inside Lua and create some magic operations to manipulate
> them, or we can store it in the clear. In the past we used the famous
> ".n" field, but there were all kinds of complains against it. Maybe
> we could store this size in t[0]? (At least it is a numeric key ;)
> -- Roberto