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

[Benoit Germain <bgermain@...>]

> -----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.

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?

So IMO, just like Paul said, a hash and a vector are different beasts, and having a single language type to express both doesn't seem that useful to me, and brings a bit confusion when it comes to using operator # if you don't know what you are doing.