[Kde-bindings] PerlQt constructor syntax

[Jonathan Yu]

Chris:

You actually can have two different versions of the same module
installed, however, if you want to use an older one you'd have to make
sure Qt4 isn't in @INC when you load Qt3. However, if you install the
modules to two totally different paths, then neither will be available
unless you add the appropriate path to @INC, which could work.

On the other hand, releasing that way means we do need to get Ashley
Winters to give us control of the namespace. I'm not sure of the
likelihood of that given the lack of response with respect to the
whole constructor question.

Right now I do have the Qt4 namespace registered, which means we can
use Qt4 and Qt4:: modules. I understand typing Qt4::PushButton might
be "ugly", but in the end it's the most Perlish thing to do, and
allows easy compatibility with Qt3. Why go through all that work just
for some 'pretty' module names?

And releasing our inner classes as Qt::PushButton will instantly mark
our class as UNAUTHORIZED unless Ashley Winters gives us the entire
namespace, which invalidates his/her modules.

Cheers,

Jonathan

On Fri, May 29, 2009 at 3:42 AM, Chris Burel <chrisburel at gmail.com> 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.
>
> 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
>>>
>>>
>>>
>>
>