[Kde-bindings] PerlQt constructor syntax

Chris Burel chrisburel at gmail.com
Wed May 27 05:24:04 UTC 2009


I originally sent this directly to who I believe are the authors of
PerlQt3, Ashley Winters and Germain Garand.  But I figured someone on
the kde-bindings list might have some input on this as well.


---------- Forwarded message ----------
From: Chris Burel <chrisburel at gmail.com>
Date: Tue, May 26, 2009 at 2:36 PM
Subject: PerlQt constructor syntax

There's a pretty lengthy discussion going on right now on perl's
module-writers list about the syntax of a new Qt4 module.  You can see
it here: http://www.nntp.perl.org/group/perl.module-authors/2009/05/msg7591.html
.  The stuff that I've done has just copied what was already working
for Qt3, so it uses the same syntax.  That means the constructor calls
look like Qt::PushButton( $parent ), as opposed to
Qt::PushButton->new( $parent ).  Also, in subclasses, you have a sub
named NEW that gets called automatically by calls to <packageName>,
like calling $foo = CustomButton() would call CustomButton::NEW.  This
function sets the value of the Qt::this() method.

It seems like a lot of that machinery is there in order to get the
'this' value to be set.  So I'm curious as to why the decision was
made to make a 'this' value.  The first thing that comes to mind is
for slot calls.  The @_ array for slots does not have a $self
reference on the front of the array, so the 'this' value is the only
way to get it.  But it seems like if the XS code already has to set
the 'this' value, it could just throw it on top of the @_ array in a
slot call.  Is there another reason why the this() value is necessary?

The other thing the constructor handles is the way things are blessed.
 Specifically, it blesses as " <packagename>" ( note the space in
front ).  Then the autoload method looks to see if it has a blessed
reference with a space in front as the first argument to the method
call, and if so, that's the object making the call.  But it seems like
you could simply test if the first argument has a valid
smokeperl_object in it, and if it does, that's the object making the
call.  Or would that break on things like copy constructors, where
you'd write Qt::PushButton( $otherButton )?  Was this put in place to
overcome some other obstacle that I don't see?

Thanks,
Chris



More information about the Kde-bindings mailing list