Re: Why no for table-iterator like e. g. "hashpairs"?

[bil til <flyer31@...>]

Sorry, but I have to defend lua here. I think it is super-great and flexible.

Just when thinking of making such a more general function (like a nicer
pack/unpack) which wants to operate on any "reasonable table", then such
"hashpairs" iterator really would be VERY nice.

When I thought why lua might put possilbe "low-indexed" keys 1,2,3... into
the hash part, I first though this somehow might happen through the garbage
collector, this then of course might get really heavy to change. But if if
this only this { "key"=value1, [1]=value2, ...} constructor problem, then it
would really VERY easy to change this I think, just by invoking some sort of
"table.normalize()" after this {} constructor (and this would be necessary
only for constructors which contain [1]... with indeces in the range 1..#t
... this should be an easy check at the end of this {} constructor function
I hope).

(A further very nice point would be, if in pairs/next iterators the hash
keys appear in the order as they were defined in {...}. Now they just seem
to be reversed. I think this might be, because the keys are a
single-linked-list ... in such a list if you create a new element, the most
fast way is to create it is at the end ... And if you created 1000 such
hashed key 20 years ago on a MHz processor, this would then have needed the
order of 1000*500usec = 0.5sec, which is quite much ... but nowadays in GHz
times, this would need only the order of 1000*500nsec, and this then is only
0.5milliseconds ... this also would be very nice for many users I think...).

Then in pairs and next it could be states, that the ipairs "fire first", and
the hash pairs "fire in the order as they were added to the table". This
would really be VERY nice for very many applications, I am very sure. (And
it would be NO restriction at all for exisitng applications...).




--
Sent from: http://lua.2524044.n2.nabble.com/Lua-l-f2524044.html