[Kde-bindings] PerlQt constructor syntax

[Jonathan Yu]

Richard:

On Wed, Jun 3, 2009 at 5:47 AM, Richard Dale <rdale at foton.es> wrote:
> 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.
There was discussion (apparently it was in a different thread, I can't
remember which, I had thought it was this one) about why it is broken.
For one thing, it's more difficult to subclass classes that are
defined in this way.

Sure, we can continue to offer this behaviour, but I believe it
belongs in a ::Compat module - it should no longer be the encouraged
way to do things.

My reasoning is that it is simply not Perlish, which causes unexpected
behaviour for those that work with Perl modules a lot (presumably,
some of the people using PerlQt will be from this category). However,
others have suggested that there are other issues, like subclassing
modules using this.
>
>> 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?)
Dominique, myself, and apparently the people hacking on Tk2, a module
with similar constraints to ours. It doesn't hurt to look at what the
rest of the community is doing.
>
>> 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.
I'm not sure I agree with this, but you're the head here and you know
what is best for KDE/Qt, so I'm on board with proceeding with the
current API. On the other hand, I think the old behaviour should at
least be marked as deprecated, or a candidate for change pending an
actual discussion. I'll consult others more experienced than I to see
whether the current API is worth keeping.

On the other hand, I think if you're expecting Perl developers to work
on your Perl software, you shouldn't be telling them to code as if
they were in C++. It's just strange, and I don't think it belongs in a
standard binding distribution; however, if that's your wish, then do
what you want. I can always release a separate API on top of it to
remove such weird (again, in my own opinion) behaviour.
>
>
>> 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.
There has been a lot of progress on OOP in the Perl community (ie
Moose et al). Moose is used in lots of different applications already.
Don't speculate on what has or has not changed when you are not
yourself a part of the very active Perl community.

It's not a research project, it is simply about what the community
seems to be shifting to. I am only trying to follow the current trends
because they are what users are beginning to expect out of modules; we
can no longer code as if it were Perl 4 (back when it was called
PERL).

The language has progressed a lot, and while there is still a fair
amount of backward compatibility to older Perls, it doesn't mean that
those old ways of coding aren't deprecated.
>
>> 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 am discussing this in the list so that anyone involved can comment.
>
>> 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.
I'm not dictating anything; I'm just following current Perl best
practices (see pretty much any OOP module published in the last year,
for example, not to mention the perl module documentation).

Again, do what you want. The beauty of open source is that if others
are sufficiently motivated by the way current things are, they are
welcome to do a fork. On the other hand, forking is bad, and that's
not something I'm inclined to do, if I can "fix" the problems I see at
the source. You might very well disagree that this isn't a problem at
all.

Currently, there don't seem to be many people using the bindings; so
what does it really matter if we make these changes, if only to make
them more clear to people used to working with Perl?

Or at the very least, I'd ask that you change the documentation to show:

my $button = Qt::PushButton->new();

versus the "old" style (from PerlQt3)

my $button = Qt::PushButton();

And then at the bottom of the perldoc have a comment stating that you
can use the old style if you wish. I still think it should be
deprecated. A port from another language is always going to involve
some amount of work; if I wanted to program in the C++ style, I'd
program in C++. But I'm not, and others using the binding are not.
They are using PerlQt4 and expecting it to be, well, Perl. That
includes the Perl philosophies, the Perl style, etc.

I suppose that this isn't important enough for me to really fork the
project, so do what you wish with it. If you decide (and Chris seems
to agree) that the current API should be kept, then I won't keep
fighting you on it.

To quote at least one other person, Bill Ward, on the module-authors Perl list:
"It [changing to using ->new rather than the current style] also makes
it easier to inherit the constructor when subclassing the module.  I
would suggest that Perl modules should be done the Perl way, rather
than by importing ideas from other languages."

But I suppose I should respect TIMTOWTDI. There's more than one way to
do it. And if you think that this is the best way for your users, then
we can proceed as if none of this discussion happened.

Judging by the code you've got, though, it would seem easier to add
the code if so desired, ie:

use Qt4::Compat;

would do that whole loop and add symbols to the symbol table as
necessary, so that the ->new part can be dropped, rather than removing
it after if that sort of behaviour is not desired (but I suppose
that's my problem, not yours).

Cheers,

Jonathan