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 _______________________________________________ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
