Re: [PROPOSAL] a new function: table.proto()

[Javier Guerra Giraldez <javier@...>]

On Tue, May 4, 2010 at 10:52 AM, Benoit Germain <bgermain@ubisoft.fr> wrote:
>> -----Message d'origine-----
>> bounces@bazar2.conectiva.com.br] De la part de GrayFace
>>
>> Why??
>>
>
> Because operator # is only relevant for tables that contain scalar keys. And even then, operator # on a table with holes will give you totally different results even when the table contents slightly change: in a table with several holes, just add or remove one, and operator # will return the index of a non-nil key preceding *any* such hole. In other words, when manipulating a table with holes, you just can't rely on operator #. Meaning, that in practice, you are stuck with scalar-keyed tables without holes, which happen to be exactly the case optimized by a table's array part.


if you want the # operator to report on content, you'll either get the
same shortcomings as the current one, or incur on heavy linearities
somewhere.

i guess you're thinking on a vector's size() operator, which is next
to useless in a dynamic language


> The same is true for the table module, and especially for table.sort. I am curious whether it could be possible to obtain a sorted table if the array optimization was absent?

no.  in fact, having the array part is quite handy to store a desired
order on a hashtable (which is intrinsically unsorted).  see how
luaExpat reports XML argument lists


-- 
Javier