[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Why no for table-iterator like e. g. "hashpairs"?
- From: bil til <flyer31@...>
- Date: Fri, 1 Nov 2019 10:24:11 -0700 (MST)
Thank you for your answers.
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".
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... .
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:
> for i= 1, 3 do t[i]= i end
> for k,v in pairs(t) do print(k,v) end
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