Re: [RFC][PATCH] Small enhancement for Glib::Object::Subclass

["muppet" <scott asofyet org>]

Jan Hudec said:
> On Tue, May 11, 2004 at 21:47:06 +0200, A. Pagaltzis wrote:
> > * Jan Hudec <bulb ucw cz> [2004-05-11 21:33]:
> > > Registering is of course possible, but it:
> > > 1) Does not look perlish. Perl seems to prefer magic names.
> >
> > Seemingly.
> >
> > There's BEGIN, END, etc, but they operate on a different level,
> > they're not functions.
> >
> > OO is traditionally magic name based (con-/destructors,
> > finalizers, etc) in most languages, so it's not particularly a
> > choice on Perl's part.
> >
> > tie() is indeed magic name based.
> >
> > Overlading, on the other hand, is not.
>
> The examples I showed (GET_PROPERTY, SET_PROPERTY, INIT_INSTANCE,
> FINALIZE_INSTANCE and especialy do_<signal_name>) are all from current
> Glib::Object::Subclass, contrary to your claim.

er, not exactly --- the all-caps ones are virtual functions of Glib::Object
itself, and are actually set up in GType.xs (meaning that they will be called
even if you just use Glib::Type::register_object() directly).  this is rather
a lot like the tie() interface, which is actually what i used as justification
for it (and the vfunc/interface stuff in general).

the do_<signalname> was probably a mistake.  i don't use it myself, and i
haven't seen any user code that uses it.  it was inspired by pygtk, iirc. 
this sucks for several reasons:

   * the name is lowercase, despite the fact that perl calls it from
     behind the scenes.  rationale:  the GtkObject::destroy signal
     would clash with DESTROY if not prefixed, and DO_<SIGNAL_NAME>
     is, well, hideous.
   * nothing else in perl uses the do_ prefix, but without it, we'd
     still have terrible, recursion-inducing name clashes, since
     there's often a method with the same name as the signal, which
     emits that signal.
   * the list of signal names is defined by the underlying library
     and can change out from under us!  with vfuncs and interfaces,
     we require binding glue and are able to know via versioning whether
     functions exist, but the dynamic nature of signals means that any
     code can create a signal whose name can result in a clash.

this third reason is why i am reluctant to implement something which turns
property names into method/function names on the fly.


-- 
muppet <scott at asofyet dot org>