[Kde-bindings] PerlQt constructor syntax

[Richard Dale]

On Wednesday 03 June 2009 03:37:59 pm Jonathan Yu wrote:
> 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.
OK, sounds good. I think I would describe it as 'could be improved' as opposed 
to 'broken', which sounds a bit bad.

> >> 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.
Yes, that's true. Probably the GTK perl bindings are the closest to the PerlQt 
ones, and I don't know what they did about GTK 1.x vs GTK 2.x.

> >> 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.
No, I'm not in charge. My suggestions were only about what would fit best with 
the KDE release schedule, and making sure that you can get everything wrapped 
up OK for when the GSOC coding period ends in mid-August. We don't have much 
'wiggle room' time for making large changes in the syntax

> 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.
No, I certainly don't want to tell anyone how to write Perl, or tell the 
PerlQt team what to do. I am not in charge of KDE bindings work, and nobody 
else is either. We discuss things only this list and others in order to 
collaborate. As the Perl, Ruby, PHP and C# bindings will be using the same 
'Smoke' libraries we will need to coordinate across bindings projects and be 
careful not to end up with forks of the Smoke libs.

> >> 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.
Ah, OK - for me 'computer science != progress on Moose' and so I misunderstood 
what you were meaning. Ashley mentioned Moose too, and it does sound like 
you're right in having a good look at it for ideas.

> 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.
Yes, and we did comment. It was just that I got the impression (possibly 
wrongly) that you weren't discussing things with Chris.

> >> 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.
No, I've no intention of forking PerlQt or even working on the Perl parts at 
all as I don't know enough about Perl. I'm only saying that if you can start 
with the current community, you've got someone to discuss improvements with. 
But if you produce an initial version of PerlQt that doesn't look like the old 
one, maybe those guys won't want to try the new one, and there won't be a 
critical mass of a community until after a longer time than otherwise. Of 
course I could well be wrong about that.

> 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?
Well there did used to be a fair number of users, and I think they would 
return if a new Qt4 version of PerlQt similar to the old one was released.

> 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.
No, you and Chris and the other Perl guys are completely in charge, and I'm 
not proposing any sort of fork at all. I'm only suggesting that the design 
would be best a result of a community discussion like the excellent one going 
on over on kde-perl at kde.org.

> 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).
Yes, that sounds good.

-- Richard