[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: hpairs?
- From: Richard Hundt <richardhundt@...>
- Date: Wed, 29 Dec 2010 16:12:07 +0100
On 12/29/2010 01:18 PM, Roberto Ierusalimschy wrote:
I use this for a JSON serializer to encode the hash part, and it
seems to work, but that may be implementation specific and not
reliable (i.e. it relies on next() returning the first key in the
hash part when given the last key in the array part). Critique?
Just yesterday I sent an example where this does not work:
t = {a=1,b=2,c=3,d=5,e=6}; t[1] = 1; t[2] = 1; t[3] = 1
for k,v in next, t, #t> 0 and #t or nil do print(k) end
Prints only '1' in my machine.
Okay, thanks, that's clearly not the way to do it then.
The "array part" and the "hash part" do not correspond necessarily with
the "sequence keys" (those returned by ipairs) and the "non-sequence
keys".
Looking at the Table struct as well as luaH_next is obviously not the
whole picture, so I'll take it as a fun exercise figuring out why that
should be :)
Please, do not refer to the "array part" or the "hash part" of a table,
unless you are discussing the implementation of tables. They are
completely invisible (except for performance).
Sorry, I'm probably an unusual case here... I spend most of my Lua
coding time writing compilers which produce PUC-Rio Lua VM bytecode
(relevant in this case is parametrising OP_NEWTABLE), so I'm biased to
thinking in terms of the implementation, which can get tricky when
implementation details leak through to semantics and you think that
that's what's intended (which, in a way, is what my question was about).
I take your Point though.
Thanks,
Richard