Re: cellrenderer GET_SIZE super method

On Jun 29, 2008, at 1:20 PM, Torsten Schoenfeld wrote:

But as far as I can tell, your suggestion of chaining up to the first parent that is not a Perl subclass does indeed fix this. It's implemented and tested in caller-v2.patch. The patch contains some more rationale of why I think this works. The patch also contains a FIXME comment detailing a scenario where this approach still results in an endless loop: a Perl class that
inherits from a C class that inherits from a Perl class.

In case you're wondering, this sort of thing would come up when using specialty embedded environments. It would be awesome if we could actually take advantage of code in various languages, e.g. pygtk class inheriting from a gtk2-perl class inheriting from a mono class inheriting from a C class... but i don't know if anybody actually *does* this in the wild.

There's a solution for this sort of situation in the base_init handling in GType.xs, which we needed for GStreamer to work correctly. At the beginning of the call chain, create a list of classes in the ancestry, and walk it on each successive call. Doing that sort of thing here for cell renderer vfunc chaining would be a bit painful, but might get the job done.

The pedantic approach to the solutions here in CellRenderer was not intended to be über perfect for CellRenderers, which admittedly don't really need to worry about the perl-C-perl-C problem. This was the easiest practical place to hit non-signal vfunc chaining, and the first place we needed to solve the problem. The approach used here would be generalized into Glib to solve vfunc chaining for everybody. (See also the Buildable chaining issue.)

muppet: what do you think?

In the words of Dr Frederick Frankenstein, It... could... work!  [1]

It's very useful to write your own cell renderer, but also very painful. This makes that less so, so it's good.

+               /* check if this class isn't actually one of ours.  if it is a
+                * Perl class, then we must not chain up to it: if it had a sub
+                * defined for the current vfunc, we wouldn't be in this
+                * fallback one here; so chaining up would result in the
+                * fallback being called again.  this will lead to an endless
+                * loop.

You might want to mention that we won't get in here for a perl class because of SUPER:: in the main perl interpreter. It took me a few times reading the comments and code and reacquainting myself with the problem to remember that.


Me:  What's that in your mouth?
Zella:  *swallows laboriously*  Nothing.
Me:  What did you just swallow?
Zella:  A booger.
Me:  Baby girl, don't eat boogers.  That's gross.
Zella:  But it was in my nose.

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