[Kde-bindings] PerlQt constructor syntax

[Richard Dale]

On Tuesday 02 June 2009 02:11:56 pm Jonathan Yu wrote:
> Hi:
>
> Unfortunately, maintaining the existing API isn't something we can do,
> because the current API wasn't considered for forward compatibility.
> If we keep the existing API as-is, we will be breaking Perl best
> practices. (For example, see the discussion about the whole Blah->new
> versus Blah(...) constructors)
But you didn't apparently read Ashley's response to Chris Burel's original 
mail:

On Wednesday 27 May 2009 09:44:23 am Ashley Winters wrote:
> --- 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++.


> The existing API is seriously broken and should be considered deprecated.
Umm, why is that? You are asserting your opinions without any sort of backup 
in the way of examples or reasons.

> What we might be able to do is provide a separate compatability API
> that will emulate the old style. However, maintaining the earlier API
> is bad for CPAN in general and will confuse people familiar with Perl
> coding.
Did you read what Chris Burel said about my point that I found Qt4::PushButton 
ugly, and whether it would be possible to have 'use Qt4;' or similar, but keep 
the classnames as they are:

On Friday 29 May 2009 08:42:42 am Chris Burel wrote:
> Sorry for my late response, I'm actually not subscribed to the
> kde-bindings list, so I didn't see the messages.
>
> I'm really on board with Richard on this one. I'd prefer to see it be
> this, and it'd be easy to change it to use this syntax:
> use Qt4;
> my $foo = Qt::PushButton->new(...);
> I don't see this as unnatural.  I think someone writing code using
> this module would know which version of Qt they're using, and would
> know that they are using Qt, so they would not be phased by the fact
> that all the calls are under the Qt namespace.
>
> Actually, I'd like the use line to be
> use Qt 4;
> and let Perl handle the version requirement, but that would mean that
> you couldn't have PerlQt3 and PerlQt4 installed at the same time.
>
> Due to the way the AUTOLOAD function works, having a Qt object that we
> call the PushButton method on is going to break things, because it'll
> get confusing to know what the first element on the argument stack
> represents.  Also, it was discussed on the perl list to have 'new' be
> the constructor, instead of a method that is the name of the class.
> So, calling $qt->PushButton->new() would mean you call
> Qt::PushButton(), and pass the result to Qt::PushButton::new... which
> makes no sense.
Chris appears to be saying something different from what you are saying, and 
yet you keep refering to 'we' in your reply. Who are the people that 'we' 
refers to apart from yourself (Domininique? who else?)

> Definitely, we are trying to work with Ashley Winters to get the
> namespace transferred to us; however until such a time as we hear back
> from him, we cannot release anything under the Qt namespace on CPAN
> (the PAUSE Indexer will simply mark the release as UNAUTHORIZED and
> people will be unable to install it without typing the full path to
> the file, ie, F/FR/FREQUENCY/Qt-4.tar.gz)
See what Chris wrote above.

> The Qt4 API is still awhile away from completion. Consider this
> advance notice that there are significant changes afoot, and while we
> understand that some people may have applications that use the Qt3
> API, it's not a reason to freeze the API as-is. Consider what would
> happen if HTML was frozen at the version 1.0 style to maintain
> compatibility with older parsers. At some point, change needs to
> happen, no matter how painful it is (we'll try to make this as
> painless as possible; but given the amount of time that has elapsed
> between Ashley's Qt modules and the current version, it's unlikely
> even Qt itself has a similar enough API for us to maintain
> compatibility that far back. Qt3, however, might be okay)
Well no actually. Qt3 was quite similar to Qt4 in a lot of ways, and I think 
people would expect the Qt4 version of PerlQt to be quite similar to the Qt3 
version. If you want to do some experiments after a first release to improve 
the api, then that seems fine, but the priority in my opinion should be 
ensuring that the Qt3 PerlQt user community have a smooth transition to the 
Qt4 version. Additionally, it would be nice to get the code in the KDE svn by 
the end of June and start on PerlKDE for KDE 4.4 or so.


> Definitely, though, users of previous versions of software are always
> a consideration. We will try our best to provide a clean upgrade path
> and I would encourage you to proffer your input there. I'm happy to
> try to accommodate your needs, but I feel we have to balance that with
> the current generally accepted best practices of CPAN/Perl modules,
> not to mention the progress we have made in computer science itself
> over the past decade or so.
Huh? Please don't give us mini lectures about CPAN, we don't need them. 

What progress has computer science made in the past decade that would affect 
Perl language bindings? I can't think of any. We are working on a practical 
project to be used by practical people to do practical things. It is not a 
research project.

> Here is what I am thinking about as of right now, which should give
> you a decent upgrade path. The previous code being something like:
>
> use Qt;
> my $button = Qt::PushButton();
> .. etc
>
> You would get something like:
> Use Qt4::Compat;
> my $button = Qt::PushButton();
> .. etc
>
> Thus, the only line of code you'd need to change, is to load the Qt4
> Compatibility API rather than the Qt3 stuff. It will try to provide as
> close an emulation of the old style, without breaking too many things
> (there are some limitations like what the CPAN indexer will put up
> with; and we cannot override the modules previously uploaded by Ashley
> et al. unless they delete them from CPAN, or at least transfer
> namespace ownership over to us). So far the latter is pending.
Well you've switched to 'I' now rather than 'we' - where does Chris Burel fit 
into this plan?

> I'd like to hear what you expect the API to be like, or perhaps to
> give us a snippet of code you use, so that we can create a
> compatibility API around that. Does that sound fair?
Yes, this is a collaborative project like all Free Software projects, and you 
are welcome to participate with the rest of us. But that is not the same as 
not listening to what others are saying, and dictating how  you think the 
project should move ahead.

-- Richard