[Kde-bindings] PerlQt constructor syntax

[Jonathan Yu]

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
>