[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Adonthell-devel] Items, take 2 (or 3)

From: Kai Sterker
Subject: [Adonthell-devel] Items, take 2 (or 3)
Date: Sun, 19 Jan 2003 11:36:30 +0100

Yesterday evening I changed the item stuff according to Alex'
suggestions. Items live entirely on Python side, but have a C++ wrapper
class. When I had finished stuff, I figured out that this was causing
some problems too. Fortunately, they are not that bad, i.e. one can work
around them. So before you reply to the problem description, please read
about the workaround as well, which will follow further below.

Okay, so what did I do? On C++ side, there's the item_base class that
inherits from py_object. As we agreed that an item _is a_ PyObject, that
seemed to be the natural thing to do.

On Python side we have the item class, containing all the basic
attributes I described in the item spec mail. This is the base class for
all items. Note that it has no access to C++ side.

That is what is causing the problems. If you instanciate an item on C++
side, you will have a "pointer" to the PyObject that is the actual item.
Via the methods of item_base and py_object, you can manipulate that

If you instanciate the item on Python side, you do not have the C++
counterpart. That however means that you cannot pass this item as
argument to a C++ method, as SWIG does not know about it (and since it
does not have a represnetation on C++ side). 

So what you have to do on Python side is instanciate an item_base
object. This can be passed to any C++ method, as SWIG does know about it
(and since it lives on C++ side). But that way you lose all the
advantages of this approach. To access the item's attributes and
methods, you'll have to use item_base, which means plenty of overhead.

This is only partly true, though. With py_object::get_instance () you
can get a "pointer" to the PyObject wrapped by py_object. If you call
that method from Python, you get a usable python instance of the item,
which you can directly access. Like:

    torch_base = item_base ("torch.item")
    torch = torch_base.get_instance ()
    torch.Charge = 50
    torch.use (...)

Of course, if we want to pass that item to a C++ method, we have to use
the 'torch_base' object.

To tell the truth, I haven't tested the code yet, so I am not entirely
certain whether above works without problems. But I don't see any reason
why it shouldn't. I'll definitely try it out this evening. Then you'll
hear from me.

Of course, if you got any thoughts on this topic, please lets hear them.
The new item_base is in CVS, btw.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]