Re: subclassing Glib::Boxed

[muppet <scott asofyet org>]

On Apr 15, 2008, at 9:33 PM, Kevin Ryde wrote:
> If I was crazy enough to want to subclass one of the Glib::Boxed  
> types,
> eg. Gtk2::Gdk::Color, where would be a good place to hang some extra
> instance data?  I see boxed is a scalar ref, and I guess adding to a
> class using that is a general perl question, though maybe the
> Glib::Boxed docs could point in the right direction.
>
> The closest I got was thinking to hold stuff separately, looked up  
> by address, [...] which of course is inaccessible to any further  
> subclasses, but in my case that'd be ok.  Is there a better way?

Your best bet is to have a perl-level cache in which you can associate  
extra data with the boxed object.  Furthermore, you want to compare  
the boxed objects by value, not by address, because the C code is  
allowed to and often does copy boxed objects at will.

I'm curious as to what you're trying to do; with more info we could  
give better alternative suggestions.


In more depth:

GObject wrappers are persistent, in that the perl object and C object  
are tied to each other in a two-way relationship.  When you pass a  
Glib::Object (perl object) to a C function and gtk+ later gives you  
that underlying GObject, you get the same Glib::Object reference back  
in perl.

GBoxed wrappers aren't like that.  They are ephemeral.  This is a  
technical limitation, because we don't have a way to create the two- 
way mapping.  Note that in several cases, the boxed objects from C are  
used only to create an equivalent native perl data structure (array or  
hash), and then destroyed.  The upshot is that even if GBoxed wrappers  
were blessed hash references, any extra data you attached would not be  
accessible in all cases.

--
I hate to break it to you, but magic data pixies don't exist.
  -- Simon Cozens