[Kde-bindings] PerlQt constructor syntax

[Jonathan Yu]

Hm.

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.

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.

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.

Cheers,

Jonathan

On Wed, May 27, 2009 at 4:17 PM, Dominique Dumont <domi.dumont at free.fr> wrote:
> Le Wednesday 27 May 2009 18:36:23 Jonathan Yu, vous avez écrit :
>> 2. that module will only map a single class/alias relationship, not
>> for the entire hierarchy. so just because you alias Qt4 -> Qt doesn't
>> mean Qt4::Button becomes Qt::Button, which is problematic for your
>> purposes.
>
> In Perl/Tk, I would use
>
> my $mw = Tk -> new ;
> my $button = $mw->Button; # calls Tk::Button::new
>
> Thus, if Tk changes to Tk2, the only code change I will have to do is:
> my $mw= Tk2->new ;
>
> Then Tk2::Button constructor would be called without further change by:
> my $button = $mw->Button; # calls Tk2::Button::new
>
> Can a similar scheme be considered for Qt* ?
>
>> And I think making behaviour predictable for Perl users is more
>> important than making an interface similar to that of another
>> language. People programming in Perl adopt the Perl philosophy, I'd
>> think.
>
> Yes, but if Perl Qt doc is missing (or incomplete), people will tend to
> fallback on native Qt doc. If Perl/Qt is too different from Qt, Qt doc will
> not be usable for Perl programmer.
>
> HTH
>
>