Re: cellrenderer GET_SIZE super method

[muppet <scott asofyet org>]

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.




[1] http://www.imdb.com/title/tt0072431/


--
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.