[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [PROPOSAL] a new function: table.proto()
- From: Javier Guerra Giraldez <javier@...>
- Date: Tue, 4 May 2010 11:07:04 -0500
On Tue, May 4, 2010 at 10:52 AM, Benoit Germain <email@example.com> wrote:
>> -----Message d'origine-----
>> firstname.lastname@example.org] De la part de GrayFace
> 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
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