Re: [Adonthell-devel] Item spec

[Alexandre Courbot]

Okay, I have read all the long discussion, here are my thoughts. Maybe
some will be redundant with what has been said after - I have to keep
most of my memory allocated for finals, sorry! ;)

First, how about having totally Pythonized objects? Where py_object will
become a simple interface to PyObject *. It would have the methods to
call Python methods, as it already have, but also set/get attribute
methods that manipulates Py_GetAttrString and Py_SetAttrString.

An item (or item_base) would inherit from this class, and the most
obvious parameters (name, categories, description, ...) would have a
special interface. But they would remain Python attributes.

Why? That way the name or description of an item is directly and easily
accessible from Python and C++. In Python:

self.name

in C++:

item.get_name();

Second, using a hierarchy of objects sounds really cool. We already
discussed about that: having for instance a "weapon" base class that
contains the attributes common to all weapons, then a "sword" subclass,
and so on...

Some methods would of course be standardized, like use, equip, and
combine (which returns a new item or None if the combinaison is not
relevant - can also modify or delete the items it has been passed).

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.

What has been pertinently said is that some objects deletions could be
automatic. Like when an oil pack is used, it should be destroyed. I
guess this could be coded in the combine method.

That's my first thoughts. I'm sure I haven't adressed all issues -
especially with the callback stuff that made Kai prefer solution C
instead of B. But no matter which direction we head to, I think it's
most important to formalize that very well on paper before thinking
about coding anything. How about this Kai? The problem is not very
complex, but quite large, and it gets hard to get it from a single
mail. Moreover we'd better avoid falling into the code-mess trap again!
:)

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