Re: the proper way to do inheritance

["muppet" <scott asofyet org>]

Chas Owens said:
> Following is an example of how I currently do inheritance.  Is this the
> "right" way?

this is perl!  there's more than one way to do it!  there's more than one way
to eat a reese's peanut butter cup.  there's more than one way to skin a cat. 
etc, etc.  consequently, there's no "right" way, there's only the way that's
best for the job at hand.  for more evasive answers, you can call me at the
unlisted number i'll post some other time in some other place.  :-)


> I remember there being some discussion earlier on changes to how
> Gtk2-Perl was doing inheritance, but it referenced things I am not
> doing (like the type system).

not just the type system, but features that rely on the type system.  if you
want to have your main widget be a GtkNotebook but also have a signal like
"config_changed" or "doohickey_frobnicated", or if you want to have new object
properties that could be seen and used by other code, you need to register
your subtype.

if you don't want those features (but who wouldn't want them?!?! ;) then you
don't need to register the class, and normal perl OO is perfectly adequate[1].

and aside from the type registration and a couple of overridable methods,
that's all there is that's different between the Glib::Object::Subclass way
and the normal perl way.



>       use base 'Gtk2::Notebook';

for this example, you'd merely replace that line with

        use Glib::Object::Subclass Gtk2::Notebook;

then you're free to implement signals and/or properties if/when you need them,
and any C functions that inspect types will see that you have a
GnomeSQLEditor__Editor, which isa GtkNotebook.


try perldoc Glib::Object::Subclass, and check out
gtk2-perl-xs/Gtk2/examples/histogramplot.pl for a full-featured example.




[1] there are many situations in which there are perfectly easy and equivalent
ways to do things with normal perl techniques and using the signal/callback
mechanism.  it's down to preference, really.  i've found that
signals/callbacks and object properties are really sweet once you figure out
how to use them effectively, and they take care of a whole slew of OO
abstraction scope issues that used to plague me (if you can hook a signal to
this event, then class A never needs to know anything about class B, which
needs to hook into that interaction; listable, typesafe properties allow you
to save object configuration without knowing anything about that object). 
using Glib for the signals makes a lot of sense because it already handles the
callback queuing you'd have to reimplement in perl.  all that said, i use the
subclasses more for specialized non-widgets than i do for widgets.

-- 
muppet <scott at asofyet dot org>