On Fri, 08 Apr 2011 16:12:27 -0400, spir <[email protected]> wrote:
On 04/08/2011 09:20 PM, Steven Schveighoffer wrote:
In reality, most times you are not using something as a key and
somewhere else
simultaneously. So while theoretically dangerous, it's easy to write
code that
isn't dangerous.
What about ref'ed objects used as keys be compared (at least as keys) by
ref -- and only by ref.
This is how Lua tables work (and the reason why they're so fast):
a = {1,1} ; b = {2,2}
t = {[a]=1 , [b]=2}
print (t[a], t[{1,1}]) --> 1 nil
a and the second {1,1} key are distinct objects. This is not often what
we mean, in the general case. Composite objects actually often are,
conceptually, *values*, like a position or color; thus, should be
compared by value.
But they sometimes represent unique "entities", like a game character,
which should be compared (as keys and everywhere else) by "unicity" --
and only that way. Comparing their state simply makes no sense.
I believe objects are compared that way by default. But you may want to
compare them based on their values.
For example, a container may want to compare equal to another container if
it has all of the same elements, regardless of whether they are the same
exact instance.
In any case, allowing non-immutable keys in the case where it's just the
references being compared is a good use case.
-Steve
