Adding more explicit ambiguous method lookup resolution for PerlQt

[Chris Burel]

Hey guys,
Sorry for double posting, but I wanted to get Ruby's opinion on this too.

One thing in PerlQt that can be very frustrating is when the bindings
cannot determine which method you intend to call based on the
arguments.  A common example of this happens with the QVariant class,
because it's essentially a union class that has constructors for a
bunch of different data types.  Consider:
my $foo = Qt::Variant(1)
results in

--- Ambiguous method QVariant::QVariant called
Candidates are:
        QVariant::QVariant( uint )
        QVariant::QVariant( int )
        QVariant::QVariant( bool )
Choosing first one...

It's frustrating because the bindings clearly know that the other
method exists, and sometimes you really do want to call the other
method.  But how should you specify which method you really want?

I was thinking that if we already have the method's signature, and it
is unique, why not let the coder specify the exact signature they want
to call?  Something along the lines of
Qt::setSignature( 'QVariant::QVariant( bool )' );
my $foo = Qt::Variant(1);
That way the coder can force the bindings to call the correct method.

It can really help for things like the QSignalMapper, that has these 2
functions:
void setMapping ( QObject * sender, QWidget * widget )
void setMapping ( QObject * sender, QObject * object )
Because of the ambiguity, the coder doesn't know if she/he should
connect to the 'mapped( QWidget * widget )' signal or the 'mapped(
QObject * object )' signal.

Thoughts?

-Chris
_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

[Jonathan Yu]

I think another thing we can do is implement objects in Perl, like:
QInt, QUint, QBool.. which we would pass to the variant method (on the
Perl side) and then have it automatically pick the right overloaded
version of the method.

Another possibility is to pass a hash reference, like:

Qt::Variant({
  1,
  type => bool
});

or something.

I'm not sure how this might be done on the Ruby side, however.

On Wed, Jun 10, 2009 at 2:09 AM, Gary L. Greene,
Jr.<greeneg@...> wrote:

> On 6/9/09 10:28 PM, "Chris Burel" <chrisburel@...> wrote:
>
>> Hey guys,
>> Sorry for double posting, but I wanted to get Ruby's opinion on this too.
>>
>> One thing in PerlQt that can be very frustrating is when the bindings
>> cannot determine which method you intend to call based on the
>> arguments.  A common example of this happens with the QVariant class,
>> because it's essentially a union class that has constructors for a
>> bunch of different data types.  Consider:
>> my $foo = Qt::Variant(1)
>> results in
>>
>> --- Ambiguous method QVariant::QVariant called
>> Candidates are:
>>         QVariant::QVariant( uint )
>>         QVariant::QVariant( int )
>>         QVariant::QVariant( bool )
>> Choosing first one...
>>
>> It's frustrating because the bindings clearly know that the other
>> method exists, and sometimes you really do want to call the other
>> method.  But how should you specify which method you really want?
>>
>> I was thinking that if we already have the method's signature, and it
>> is unique, why not let the coder specify the exact signature they want
>> to call?  Something along the lines of
>> Qt::setSignature( 'QVariant::QVariant( bool )' );
>> my $foo = Qt::Variant(1);
>> That way the coder can force the bindings to call the correct method.
>>
>> It can really help for things like the QSignalMapper, that has these 2
>> functions:
>> void setMapping ( QObject * sender, QWidget * widget )
>> void setMapping ( QObject * sender, QObject * object )
>> Because of the ambiguity, the coder doesn't know if she/he should
>> connect to the 'mapped( QWidget * widget )' signal or the 'mapped(
>> QObject * object )' signal.
>>
>> Thoughts?
>>
>> -Chris
>> _______________________________________________
>> Kde-bindings mailing list
>> Kde-bindings@...
>> https://mail.kde.org/mailman/listinfo/kde-bindings
>
> I agree with this, since it's bit me more than a few times, and would
> (surprise, surprise) make working on KDE bindings for Perl that much easier
> since there are times in the code (especially in the XMLGUI stuff) where a
> similar aspect occurs for the various template segments. Richard, you're
> thoughts?
>
>
>

_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl