[Kde-bindings] PerlQt constructor syntax

[Chris Burel]

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.

If all we have to do is get Ashley to add us as contributors to the Qt
module on CPAN to avoid CPAN's 'UNAUTHORIZED RELEASE' message, I think
that's the best way to go.  (The unauthorized release message
apparently happens when your module has functions in namespaces that
aren't owned by you.)

Richard, I may end up doing KDE bindings as well.  It's always been my
plan to commit my code to the kde-bindings package, but when I first
started, I had no idea what I was doing, and I didn't want to pollute
you guy's codebase.  But now that the Qt bindings have gotten as far
as they have, I definitely plan on committing them.  Would you like to
see that happen sooner rather than later?  I don't care one way or the
other if development happens at the Google Code repository or the KDE
one.

On Thu, May 28, 2009 at 8:21 PM, Jonathan Yu<frequency at cpan.org> wrote:
> Hm Dominique, you raise some very good points.
>
> Chris, I'd like to hear what you think about this; if you think it
> would work, then I can begin changing the interface over immediately.
>
> Cheers,
>
> Jonathan
>
> On Thu, May 28, 2009 at 3:26 PM, Dominique Dumont <domi.dumont at free.fr> wrote:
>> Le Thursday 28 May 2009 05:08:48 Jonathan Yu, vous avez écrit :
>>> I'm not sure if it's an entirely good idea for people to expect that
>>> changing from one version to another will mean that all the parameters
>>> have the same values as before.
>>
>> That's not the whole idea.
>>
>> When changing the first constructor call from Tk->new to Tk2->new, I expect
>> the developer to estimate the impact and test the results.
>>
>> If the Tk to Tk2 migration means that 90 % of the calls have not changed, this
>> means that only 10 % of the call needs to be reviewed. And I expect these
>> changes to be concentrated on some widget, not scattered on all.
>>
>> In you proposal, 100% of the calls need to be changed.
>>
>> And don't forget that keeping compatibility is much easier in Perl than in C
>> or C++.
>>
>>> Sure, in the simple case, what you are proposing is convenient.
>>> However, I'm not sure this will work in practice if there are
>>> parameters involved that change from version to version.
>>
>> In all cases, major changes means that the code will need to be reviewed and
>> adapted. I'm just looking to minimize the work and leave alone module that
>> would not need changes.
>>
>>> Perhaps what we could do in that case to ease a transition is to
>>> provide a script which will automatically upgrade your existing
>>> script, by going through it using PPI and changing the necessary
>>> calls, so we can rearrange things based on feature changes. The final
>>> thing would need to be checked over, but I think it's much better that
>>> way.
>>
>> Yes, that's a possibility, but all code would need to be changed and re-
>> delivered. And you would need to support all the developers that would use
>> such script for the migration. Think 10 years from now and assume as many Qt
>> modules as they are Tk modules now.
>>
>> Hope this helps
>>
>>
>>
>