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

[bil til <flyer31@...>]

Thank you for your answers.

@Francisco:

But these tables you cite here have NO indexed / list part.

(as they do NOT start at 1).

So for your tables print(#t) gives zero ... they are
"hash only" tables ...

... I want only a clear statement about the indexed / 
list part of the tables ... if a table has NO indexed part,
then it is ok for me, that the order will be "accidential".

@ Roberto:
This example is really disturbing I must admit.
Here really #t will give 3, but strangely the pair
iterator strangely starts with x, y, 3, 1, 2... .

Very odd!

But you have to admit, that this is a "somehow 
bizarre" constructor, using a constructor which 
lists the indexed items "at the end".

If you do it in a "more normal way", also possibly
the hashed key first, but then the indexed table
in a separate command, then all fine:

> t={x=1,y=2,}; 
> for i= 1, 3 do t[i]= i end
> for k,v in pairs(t) do print(k,v) end
1       1
2       2
3       3
y       2
x       1

So could we agree for the following statement:
The indexed part of a "regularly constructed table"
should be constructed separately from the 
hash part. Or if one constructor command is used,
the constructor must start with the indexed part.

If I iterate such a "regularly constructed table"
with pairs (or next), then
the iteration will ALWAYS start with the
listed / indexed range 1...#t, and this range
will ALWAYS appear "nicely ordered".

Or do you have also a counter-example against this?






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