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

[Benoit Germain <bgermain@...>]

> De : lua-bounces@bazar2.conectiva.com.br [mailto:lua-
> bounces@bazar2.conectiva.com.br] De la part de steve donovan
>
> The reason for not exporting it as part of the public API is that it
> exposes the implementation detail that tables have a hash part and an
> array part.  But it really can be _useful_...

Isn't this implementation detail already indirectly exposed by the existence of pairs/ipairs? I'll bet that not one single real-life application wouldn't experience some problems with tables if the implementation did change.

Depending on the way items are inserted in the table, iterating over them yields a different order

> t={}
> for i=1,10,2 do t[i] = i end -- items stored in hash part
> for k,v in pairs(t) do print(v) end
1
5
9
7
3
> for k,v in ipairs(t) do print(v) end -- is entry 1 stored in array part after all?
1


> t={}
> for i=1,10,1 do table.insert(t,i) end -- items stored in array part
> for i=2,10,2 do t[i]=nil end -- items moved from array to has part because of holes, but original order is preserved
> for k,v in pairs(t) do print(v) end
1
3
5
7
9
> for k,v in ipairs(t) do print(v) end -- somehow entry 1 remained in the array part?
1

Depending on the number of removed items, operator # yields (un)usable values

> t={}
> for i=1,10,1 do table.insert(t,i) end
> for i=2,10,3 do t[i]=nil end -- table now contains 1 3 4 6 7 9 10, not enough holes to move items in hash part
> print(#t)
7

> t={}
> for i=1,10,1 do table.insert(t,i) end
> for i=2,10,2 do t[i]=nil end -- table now contains 1 3 5 7 9, too many holes, stored in hash part
> print(#t)
1

So, yes, maybe this is an implementation detail, but one that everyone must be aware of in order not to be bitten by strange behaviours. So we either get rid of anything in the language that makes this apparent (like the table module - bye bye sorted tables), or we accept that this is more than an implementation detail, and the reason for not exposing the function to the language no longer really holds.

But don't ask me which solution I prefer, I don't know. As it happens, were something to change, what I would advocate would be to have the current table changed to a pure hash, and the addition of another separate "vector" type.