Re: [Adonthell-devel] Item spec

[Alexandre Courbot]

> Hm, the more I think about this, the more I like it. I imagine that
> most item attributes would be accessed from python side, so it'd
> eliminate the overhead of retrieving them from the C++ class each
> time.

Even better, we could use the Python serialization to save/transfert our
items!(provided every attribute is serializable, of course)

> > About the charges and stack items: IMO charges should be items of
> > their own. Let's take the lamp example again. The lamp is an item.
> > Oil packs are items too. When combining an oil pack with a lamp, the
> > lamp gets loaded, and the pack destroyed. All this is coded in the
> > "oil pack" combine method, when the passed item is a lamp.
> 
> Of course. Only I would do it the other way round: lamp.combine (oil).
> If the item being charged handles charges, it can easily handle
> different objects as charge. Simply make them all the same type
> ("Lampfuel") and check for that type. (Don't know what else could be
> used in lamps, but there might be items where this actually makes
> sense.)

You're right. Especially if the oil pack gets destroyed after the
combinaison. I wouldn't like having to type "del self"! :)

> Still the lamp needs a "charge" attribute to tell _how much_ oil is
> inside. After all, a lamp can have more states than full and empty :).

Yep!

> Well, sometimes you just have to try something out. The simple torch
> example already revealed a number of problems with the stuff I've
> written in the original mail. Coding something doesn't hurt, as long
> as we're ready to throw stuff away if we come up with something
> better. I mean, we're doing this all the time :). 
> 
> Also, you have to start somewhere, otherwise we talk and talk and
> nothing happens afterwards, as often was the case. Talking and coding
> at the same time might get things actually done.
> 
> Besides, what we talk will surely benefit from the practical
> experience we make with the code.

You're also right. Still, some paper clearly describing it is cool as
well :) I'll have a look at the code and see if something hits me. I
suggest we start slaughtering the Python module in 0.4. Keep in mind
that the Python module will only be used on the server side - we might
use Python on the client as well, but only for convenience (SWIG & co).
Do you want me to rewrite py_object or shall I concentrate on the tools
and let you do? (there's nothing really special in it anyway!)

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