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

[bil til <flyer31@...>]

Hi nobody,
thank you for the proposal   "function nonipairs( t )  return next, t, #t 
end" ( I think it should better say "... next( t, #t) ..." here, but I
understand what you mean).

... just the problem is, that this definitely will be definitely a dangerous
construction.

Depending on the table type, this will create either something nice, or
something very stupid:
- if t is nice (thus some linear array part, and then some hashs, so e. g.
from some number list + some hashes, e. g. {5, 10, 3, 4, 5, [key1]="v1",
[key2]="v2"), then #t also nice, then it will work.
- if t is made from constructs like {[key1]="v1", [key2]="v2", [1]=5,
[2]=10} then it is completely unclear, what next(t,#t) will return, so in
this case it will be dangerous (possibly it would deliver a key after key1,
key2, so such iteration with "skip" key1 and key2, in which I would be
really interested...).

I would like to have such an hpairs which would give me fast access to the
table hash part in ANY "table case". (I would NOT mind, if also SOME FEW
"index part" keys like 1, 2 pop up in this iteration, but please FOR SURE in
any table the hash keys ("key1", "key2" in example above) MUST pop up in my
iteration).



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