[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: tables
- From: "D Burgess" <dburgess@...>
- Date: Mon, 6 Mar 2006 16:52:18 +1100
Chris wrote:
> [...] I probably shouldn't have gotten
> involved in this conversation in the first place. :)
Lots of passionate responses.
I initially asked a question. Thanks for the replies.
Having reviewed a few historical list mails, I should point out
that one of the reasons for # was to provide a syntactically
cheap way of table (array) appends, the example provided by
Luiz was:
t[#t +1] = newvalue
So that arrays do not have to be reconstructed and so that we
dont have to use (next(t)) == 1 as test for emptiness, it would
be convenient (and consistent) if the # operator provided the
following behaviour (this is the assertion):
"# provides the same number as the number of iterations
provided by ipairs".
e.g.
n=0 ; for i,v in ipairs(t) do n=n+1 end
and
n = #t
"should" provide the same result
which means that
for i,v in ipairs(t) do
and
for i = 1, #t do
would provide the same number of iterations.
This IMHO would provide an improvement in the behaviour of
the language and a simplification of the doco. I would not be too
fussed if the rule allowed for arrays to be iterated starting at
numbers > 1. This argument is about # and ipairs consistency.
I note with some interest that the deprecated table.foreachi()
provides the consistency that ipairs() does not.
David B.
- References:
- tables, D Burgess
- Re: tables, Chris
- Re: tables, Chris
- Re: tables, D Burgess
- RE: tables, Dolan, Ryanne Thomas (UMR-Student)
- Re: tables, D Burgess
- RE: tables, Dolan, Ryanne Thomas (UMR-Student)
- Re: tables, Chris
- Re: tables, Alex Queiroz
- Re: tables, Chris