Re: Definition of table.insert
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: Definition of table.insert
- From: Dirk Laurie <dpl@...>
- Date: 2011年1月11日 10:30:02 +0200
On Tue, Jan 11, 2011 at 09:05:12AM +0200, Henning Diedrich wrote:
> You also stress by that, that table must not be seen as one type, but two
> in one. I would suggest that's also too complicated. A table should not
> behave differently depending on how it has been treated before. Simple
> as that in my eyes.
>
Undefined behavour is just that: undefined.
Could you narrow down your objection as a disagreement with one of the
following propositions?
1. Lua has one and exactly one sophisticated data structure: a table,
which is a map from a set of keys to a set of values. Both these
sets are subsets of the set of first-class values.
2. nil is not a first-class value and may therefore not be either
a key or a value. Constructions like
if t[a]==nil ...
t[b]=nil
are nothing else than translations of statements like
"If t does not contain the key a ..."
"Remove b from the set of keys of t"
into Lua syntax.
3. The keys 1,2,3,...,n occur particularly often, and for our convenience,
a table constructor is provided that implicitly assigns those keys
so that we need only specify values. A nil value given to that
constructor means: don't associate anything with that key just yet.
4. Certain functions such as ipairs, #, table.insert and table.remove
are designed to make life easier for us when the numeric keys in
our table form just such a continuous block.
5. If you wish to use those functions, you should not use any numeric
keys outside the block, and also not allow any key properly inside
the block to be removed.
6. Lua does not actually check that you have been law-abiding when you
do use these functions, but (except ipairs and to some extent #)
the result is undefined and you should not rely on any property
that in a particular implementation they have been observed to
possess.
Dirk