On Tue, May 11, 2004 at 16:20:50 -0400, muppet wrote:
Jan Hudec said: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.
I don't think DO_<signal_name> it's that horrible. And it certainly won't cause clashes, as one usualy don't use such strangely mixed-case identifiers.
* 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.
Well, I actualy got into habit of using do_ prefix for the core function that does the dirty work once input is sanitized etc. when I was writing in linux kernel. So I might actualy happen to unintentionaly write such function.
* 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.
Which, I believe, does not apply to properties. The property setter is always called from the package that defined the property. Or is it not?
this third reason is why i am reluctant to implement something which turns property names into method/function names on the fly.
It does not apply that much there.
But generaly yes, moving the functionality to
Glib::Type::register_object would be better idea. On the other hand,
it's more difficult to write and test. And I don't understand the
internals of gtk2-perl that good.
-------------------------------------------------------------------------------
Jan 'Bulb' Hudec <bulb ucw cz>
Attachment:
signature.asc
Description: Digital signature