Re: [Adonthell-devel] item equality

[Kai Sterker]

On 05 Feb 2003 14:18:38 +0100 Alexandre Courbot wrote:

> 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.

Well, yeah, I could live with that. But it would only eliminate some
minor problems. Consider the following:

Character A has 50 arrows, character B none. A wants to give 20 arrows
to B. So 20 arrows (i.e. a pointer to A's arrow item and the quantity
20) are passed to B's inventory. We search B's inventory for arrows and
find none. But we cannot add a pointer that points to an item in A's
inventory, because A may use his arrows up. In this case, the arrow item
would be deleted, because there is no way to tell that it is also used
in B's inventory. So to add the 20 arrows to B's inventory, we need to
clone the arrow item. And if we can clone an item, nothing speaks
against stacking mutable items as well. When one of the stack is about
getting used, we clone it and use the clone instead.
 
As I said in the mail about mutable and immutable items, we could get
around the cloning if we only had one item instance of each kind and
worked with refcounts. But that only works for immutable items. Mutable
items had to be handled different, but I hadn't any good ideas yet.


> > 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!).

I think so. There are 2^128 different hashes. That are quite a few:
   
    340,282,366,920,938,463,463,374,607,431,768,211,456

I would be very surprised if we had a collision. Further, the chance
that two items with the same hash also have the same name is practically
0. 


 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.

It's called __eq__ and new in Python 2.2. I haven't the newest python
docs on this box, but I remember that there were some caveats when
defining this method. Also, when comparing the hashtable, you'd almost
certainly end up in trouble with non-trivial items. Items containing an
inventory or events, for example. Of course, the same problem exists
when calculating the hash, so that's no good excuse ;).


> 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!

I would like to, but right now I am not certain into which direction to
go; both the single item approach and the current implementations have
their strengths and weaknesses. Especially when it comes to implementing
the inventory. I have some half-finished spec of that, but since I might
redesign the items, I haven't completed it, and therefore can't post it
yet.

I hoped that I'd wake up one day with a perfect solution in my mind, but
that hasn't happend so far ;).

Kai