[Kde-bindings] PerlQt constructor syntax

[Ashley Winters]

--- On Tue, 5/26/09, Chris Burel <chrisburel at gmail.com> wrote:
> That means the constructor calls
> look like Qt::PushButton( $parent ), as opposed to
> Qt::PushButton->new( $parent ).

Both versions work in PerlQt 3. In fact, the code involved is literally:

    # for my $class ("Qt::PushButton") ...
    *{ $class } = sub {
        $class->new(@_);
    } unless defined &{ $class };

The shortened form was encouraged to ease the conversion from C++.

> 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.

The purpose of NEW was to hook the object creation, and obscure the fake classname being used to bless the object. It serves a need similar to BUILD in Moose.

> 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.

It was an arbitrary decision. I liked the possibility of writing programs which looked like http://perlqt.sourceforge.net/index.php?page=viewcode&file=examples/drawlines/drawlines.pl

> Is there another reason why the this() value is necessary?

It exists primarily to support unqualified object attributes. There are many classes to do such things today, although now I would turn to Moose. The 'this' hack existed because C<has foo => (is => ro)> wasn't an option back then. If MooseX::Declare was more mature, it would be the perfect platform for Qt the way I always wanted it.

> 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.

The class hierarchies of the plain and the space-prefixed classes are different. The normal (non-prefixed) classes had the same inheritance tree as Qt C++. The space-prefixed classes had no @ISA parent (until later, when operator overloading was added), and therefore immediately failed over to AUTOLOAD.

That served as a method optimization lookup on any object which was not subclassed by Perl.

> Was this put in place to
> overcome some other obstacle that I don't see?

AUTOLOAD was always tricky. There are hacks upon hacks required to get it to work to any reliable degree across perl versions, and then more hacks on top to make it perform at any respectable speed. It all depends on what versions of perl you want to support.

Regards,
- Ashley Winters