Re: [Adonthell-devel] item equality

[Alexandre Courbot]

> The question is, how does the inventory figure out whether an item you
> pick up fits to an existing stack? It's simple with coins. But imagine
> torches were stackable. You could have a torch that is half-burnt in
> your inventory, and you pick up a new one. Should they be stacked?
> Possibly not, because stacking means something like increasing a counter
> that comes with each slot. After all, if a character carries 1000 coins,
> that shouldn't be 1000 individual items! Instead it should be one item
> with count 1000.

While I agree that coins should be stackable, I'm not as sure about
torchs. How about considering "stackable" items as one item with a
quantity control? Like the coins. You wouldn't say "one coin" but a coin
item with a quantity (which is the actual number of coins). That way,
when adding a coin item in the inventory, you'd simply combine it with
your current coin item (that every character should have), and this will
simply add the quantities. This would also work with arrows (of the same
types of course - you won't combine wood arrows with silver arrows for
instance). Objects like torchs wouldn't be stackable, but since their
state can change, it doesn't shock me. Only very basic items should be
stacked IMO.

> Roughly equal seems to be easier, so lets cover that first. Is it
> reasonable to assume that items with equal name are at least "roughly
> equal"? I can't think of any example where this wouldn't be the case.
> Any thoughts on this?

The name of an item should totally identify the class of the item (not
the instance), so it sounds good to define a rough equality. Total
equality would then mean instance equality.

> So I thought that we could perhaps create a hash of an item's
> properties. That together with the item name should help to check
> whether items are equal or not. The hash could even be saved with the
> item, so it only has to be regenerated when a change is made to an item,
> which shouldn't happen too often.

Good idea! Although we might be very unfortunate and get two differents
objects with exactly the same hash, but that'd really be unfortunate
(guess we have more chance to be hit by lightning!). Your implementation
in your next mail looks good too. But wouldn't it be possible to, say,
automake the equality test? Instead of overloading __setattr__, you'd
overload __equal__ (don't remember if it's the correct name), and this
method would simply check the equality of all the members, one by one
(since every object is a hash table, you can do a "for attribute in
self:" I think, and check both the keys and their value). The equality
test would cost more, but on the other hand we wouldn't have to
recalculate the hash. Remember that the state of some objects will
change often (a burning torch for instance). I think that state changing
will happen much more often than equality checking.

Anyway, this is just an idea. And either way, we can change the equality
test without any other change to the item code - so I'd say you can go
ahead!

Alex.
-- 
http://www.gnurou.org