[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bindings
Subject:    Re: [Kde-bindings] PerlQt constructor syntax
From:       Ashley Winters <jahqueel () yahoo ! com>
Date:       2009-05-27 8:44:23
Message-ID: 626201.72658.qm () web50807 ! mail ! re2 ! yahoo ! com
[Download RAW message or body]


--- On Tue, 5/26/09, Chris Burel <chrisburel@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



      
_______________________________________________
Kde-bindings mailing list
Kde-bindings@kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings


[prev in list] [next in list] [prev in thread] [next in thread]