[Kde-bindings] PerlQt constructor syntax

Gary Greene greeneg at tolharadys.net
Thu Jun 4 15:36:17 UTC 2009


On Thursday 04 June 2009 06:09:49 am Jonathan Yu wrote:
> Hm, very strange. Looks like Ashley's e-mails to the list were being
> dropped by Gmail, which is why my conversation seemed out of sync with
> what was being discussed.
>
> Anyway, one thing that Ashley mentioned is:
> It all depends on what versions of perl you want to \
> support.
>
> So just what versions would we like to consider supported? I'd submit
> that anything before 5.6.1 is absolutely insane to support; anything
> before even 5.8.8 seems a bit ludicrous (even Perl 5.10.0 was released
> over a year ago) -- "5.10.0/ 2007-12-18; 534 days ago." Perl 5.8.8 was
> initially announced on 2006-02-02.
>
> But that's totally up to you guys, and it has quite a bit of influence
> on what we're really allowed to do (a lot of features just aren't
> supported that far back, and it's a lot of work to hack it in).
>
> Cheers,
>
> Jonathan
>
> On Thu, Jun 4, 2009 at 6:14 AM, Richard Dale <rdale at foton.es> wrote:
> > 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
> > _______________________________________________
> > Kde-bindings mailing list
> > Kde-bindings at kde.org
> > https://mail.kde.org/mailman/listinfo/kde-bindings
>
> _______________________________________________
> Kde-bindings mailing list
> Kde-bindings at kde.org
> https://mail.kde.org/mailman/listinfo/kde-bindings

My gut feel is to ignore the 5.6.x series since any machine still using it 
won't be able to install Qt4 anyway (compiler incompatibilities). While 5.10 
is nice, 5.8.x should be the baseline target with upwards support for the 5.x 
family.

-- 
Gary L. Greene, Jr.
Sent from: peorth.tolharadys.net
 08:34:26 up 31 days,  1:00,  4 users,  load average: 0.58, 0.65, 0.62
==========================================================================
Developer and Project Lead for the AltimatOS open source project
Volunteer Developer for the KDE open source project
See http://www.altimatos.com/ and http://www.kde.org/ for more information
==========================================================================

Please avoid sending me Word or PowerPoint attachments.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-bindings/attachments/20090604/2fda5716/attachment.sig>


More information about the Kde-bindings mailing list