Re: could not find signal invocation hint

[muppet <scott asofyet org>]

On Nov 28, 2005, at 9:42 PM, James Muir wrote:

> muppet wrote:
>
> > $self->SUPER::ripen; # does what you want.
> Thanks for cutting through my confusion. I gotta check my PANEXA  
> prescription :-) . I was and probably still am mis-reading the  
> Glib::Object::Subclass and the "Subclassing Widgets in Perl"  
> documents.
>
> I'm unclear as to what the following section from the  
> Glib::Object::Subclass document is trying to tell me. Are the "Base  
> Methods" the INIT_INSTANCE, SET_PROPERTY etc methods or just any  
> widget method such as 'size_request'?

INIT_INSTANCE, SET_PROPERTY, et al are not methods --- they are  
functions.  The distinction here is that they are *not* inherited,  
but called with an explicit package name.

What the section refers to as "base methods" are virtual methods  
defined by a base class.  It's not "any widget method", only the  
virtual ones, and there are two ways to do it.  The explanation gets  
into some history and details, so i'll try to be as clear as possible.

"Virtual method" means that the method is defined by a base class but  
implemented by a child class.  This is important in statically-typed  
languages where the actual code to call is determined at compile  
time; virtual methods allow you to defer the choice until runtime by  
using indirection.  In dynamically-typed languages like perl where  
methods are always looked up at runtime, this distinction is mostly  
academic... except where you try to blend to two paradigms.


> I understand that signals allow for a class closure (nice feature),  
> but I'm confused as to how or why events come into the picture at  
> all for overriding methods.

Partly coincidence, partly history.

- All events have signals associated with them.

- In the old days, gtk+ policy was to have a signal for every virtual  
method to allow the use of signal closure machinery for overriding  
virtual methods from language bindings.

Since the old days, there have been several virtual methods added  
without signals, and these are, unfortunately and necessarily,  
handled by completely different machinery in gtk2-perl; luckily, it's  
much more like normal perl.  See the docs for Gtk2::CellRenderer.


> The Gtk2::Widget class has a 'size_request' method, so it seems  
> that the name of the method is being placed into the signal hash  
> and it references a subroutine to override the method. Is this to  
> work around Glib issues?

It's to avoid an infinite loop.  If size_request went to invoke your  
handler, which was called size_request, which tried to chain up to  
size_request, which tried to invoke your handler, which was called  
size_request, which tried to chain up to size_request...

The basic problem is that you're providing methods that will be  
invoked indirectly, that is, not from perl code.  We made a design  
decision not to automatically turn signal names into method names,  
because of the possibility of name collisions (e.g.  Gtk2::Object's  
"destroy" signal would become "DESTROY", which is very special in perl).



> Not sure when it is appropriate to use the scheme described below  
> to override a method.

If there is a signal associated with a method, then that signal is  
provided so that you can override the method.  Use it.


> Thanks for your help in clarifying this.

Not sure i actually clarified anything...



--
To me, "hajime" means "the man standing opposite you is about to hit  
you with a stick".
  -- Ian Malpass, speaking of the Japanese word for "the beginning"