Re: [Swig-user] Working with object identities in target languages

[Daniel O. <DOb...@ca...>]

Josh,

Thanks for the help!  It is quite useful.

I've started tinkering with this, and it seems that this is going to be
the right approach for my project.  I can also overload __hash__ and get
the key/dictionary behavior that I want.

Regarding the "-modern" flag and "object" base class.

I need to switch over to this.

What is the C++ class that would correspond to the Python "object" base
class?  Are you saying that I would have to define a base class named
"object" myself?  Is it possible to map a differently named C++ base
class to the Python "object" class?

Sincerely,
Dan

Daniel M. Oberlin
CambridgeSoft Corporation
100 CambridgePark Drive
Cambridge, MA 02140 USA
617.259.9959
dm...@ca...


-----Original Message-----
From: Josh Cherry [mailto:jc...@nc...] 
Sent: Wednesday, April 09, 2008 10:10 AM
To: Daniel Oberlin
Cc: swi...@li...
Subject: Re: [Swig-user] Working with object identities in target
languages



On Tue, 8 Apr 2008, Daniel Oberlin wrote:

> a = container.GetObject()
>
> b = container.GetObject()
>
>
>
> a == b -> false
>
>
>
> This also precludes the usage of target-language references as unique
> identifiers in associative arrays (dictionaries).


> 2.       I assume that the answer to the previous question is "no", or
> "not easily.  If that is the case, then how (in practice) does one
work
> with object identities in the target language?  Are there any
> conventions for dealing with this problem?

As you may know, the "identity" in the sense of the address of the C++ 
object is contained in the "this" member of a Python proxy instance.
You 
could do things with that.  I imagine you could make == do what you
want, 
though "a is b" would still not do what you want.  You can provide 
your own == behavior by defining __eq__.  If your objects all derive 
ultimately from "object", as will be assured if you use -modern (except 
maybe exception classes), you can provide your own class named "object" 
early on and define __eq__ there.  Then it will work for all your 
classes, except those that overload __eq__ themselves.

That last point illustrates another aspect of the ambiguity of proxy 
instances?  What are they?  Instances?  Pointers?  Pointers to pointers?

Comparisons analogous to comparing all of those make an appearance.

Josh