Duplicate methods for QByteArray::data()

[Chris Burel]

I was trying out the new smokeqt object that's generated with Arno's
new generator, and I discovered that there are 2 methods for
QByteArray::data(), one that returns const data and one that doesn't.
Is this by design?  I thought that the only methods that were
considered ambiguous were ones that have the same name and number of
arguments, but different types of arguments.  Should I change the
ambiguous method resolution code in PerlQt4 to handle this case, or is
it something that can be fixed in smoke?

grep QByteArray::data smokedata.cpp
    {64, 7190, 0, 0, 0, 1692, 17},      //1927 QByteArray::data()
    {64, 7190, 0, 0, Smoke::mf_const, 2113, 18},        //1928
QByteArray::data() const

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

[Arno Rehn-3]

On Friday 06 November 2009 04:32:23 Chris Burel wrote:

> I was trying out the new smokeqt object that's generated with Arno's
> new generator, and I discovered that there are 2 methods for
> QByteArray::data(), one that returns const data and one that doesn't.
> Is this by design?  I thought that the only methods that were
> considered ambiguous were ones that have the same name and number of
> arguments, but different types of arguments.  Should I change the
> ambiguous method resolution code in PerlQt4 to handle this case, or is
> it something that can be fixed in smoke?
>
> grep QByteArray::data smokedata.cpp
>     {64, 7190, 0, 0, 0, 1692, 17},      //1927 QByteArray::data()
>     {64, 7190, 0, 0, Smoke::mf_const, 2113, 18},        //1928
> QByteArray::data() const

This is done on purpose. There are some use cases, especially in QtDBus, where
you need the 'const' version of a method. Depending on whether the method is
const or not the returned value differs. Most of the time it will suffice to
simply call the non-const method, though.

--
Arno Rehn
arno@...
_______________________________________________
Kde-bindings mailing list
Kde-bindings@...
https://mail.kde.org/mailman/listinfo/kde-bindings

[Chris Burel]

> There are some use cases, especially in QtDBus, where
> you need the 'const' version of a method. Depending on whether the method is
> const or not the returned value differs.

Really?  The only thing that looks different is the call to detach().
And if you really want the const data, couldn't you use constData?
inline char *QByteArray::data()
{ detach(); return d->data; }
inline const char *QByteArray::data() const
{ return d->data; }
inline const char *QByteArray::constData() const
{ return d->data; }
_______________________________________________
Kde-bindings mailing list
Kde-bindings@...
https://mail.kde.org/mailman/listinfo/kde-bindings

[Ian Monroe-6]

On Fri, Nov 6, 2009 at 4:43 PM, Chris Burel <chrisburel@...> wrote:

>> There are some use cases, especially in QtDBus, where
>> you need the 'const' version of a method. Depending on whether the method is
>> const or not the returned value differs.
>
> Really?  The only thing that looks different is the call to detach().
> And if you really want the const data, couldn't you use constData?
> inline char *QByteArray::data()
> { detach(); return d->data; }
> inline const char *QByteArray::data() const
> { return d->data; }
> inline const char *QByteArray::constData() const
> { return d->data; }

Arno was saying that this distinction was needed for methods in
QtDbus, not that it was required for QByteArray.

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

[Chris Burel]

2009/11/6 Ian Monroe <ian.monroe@...>:

> On Fri, Nov 6, 2009 at 4:43 PM, Chris Burel <chrisburel@...> wrote:
>>> There are some use cases, especially in QtDBus, where
>>> you need the 'const' version of a method. Depending on whether the method is
>>> const or not the returned value differs.
>>
>> Really?  The only thing that looks different is the call to detach().
>> And if you really want the const data, couldn't you use constData?
>> inline char *QByteArray::data()
>> { detach(); return d->data; }
>> inline const char *QByteArray::data() const
>> { return d->data; }
>> inline const char *QByteArray::constData() const
>> { return d->data; }
>
> Arno was saying that this distinction was needed for methods in
> QtDbus, not that it was required for QByteArray.
>
> Ian

Ah, ok, that makes a lot more sense.  How does the ambiguous method
resolution work for those cases?  And can you guys point me to some
specific examples so that I can make test cases?
_______________________________________________
Kde-bindings mailing list
Kde-bindings@...
https://mail.kde.org/mailman/listinfo/kde-bindings

[Arno Rehn-3]

On Saturday 07 November 2009 00:19:06 Chris Burel wrote:

> 2009/11/6 Ian Monroe <ian.monroe@...>:
> > On Fri, Nov 6, 2009 at 4:43 PM, Chris Burel <chrisburel@...> wrote:
> >>> There are some use cases, especially in QtDBus, where
> >>> you need the 'const' version of a method. Depending on whether the
> >>> method is const or not the returned value differs.
> >>
> >> Really?  The only thing that looks different is the call to detach().
> >> And if you really want the const data, couldn't you use constData?
> >> inline char *QByteArray::data()
> >> { detach(); return d->data; }
> >> inline const char *QByteArray::data() const
> >> { return d->data; }
> >> inline const char *QByteArray::constData() const
> >> { return d->data; }
> >
> > Arno was saying that this distinction was needed for methods in
> > QtDbus, not that it was required for QByteArray.
> >
> > Ian
>
> Ah, ok, that makes a lot more sense.  How does the ambiguous method
> resolution work for those cases?  And can you guys point me to some
> specific examples so that I can make test cases?

QtRuby and Qyoto still default to the non-const version and don't have a way
to use the const one. The lisp bindings now have a public field that can be
set and depending on the value you can call the const or non-const method.
Tobias Rautenkranz is the developer of these bindings, he probably has more
information on that.

--
Arno Rehn
arno@...
_______________________________________________
Kde-bindings mailing list
Kde-bindings@...
https://mail.kde.org/mailman/listinfo/kde-bindings

[Richard Dale-5]

On Friday 06 November 2009 02:14:12 pm Arno Rehn wrote:

> On Friday 06 November 2009 04:32:23 Chris Burel wrote:
> > I was trying out the new smokeqt object that's generated with Arno's
> > new generator, and I discovered that there are 2 methods for
> > QByteArray::data(), one that returns const data and one that doesn't.
> > Is this by design?  I thought that the only methods that were
> > considered ambiguous were ones that have the same name and number of
> > arguments, but different types of arguments.  Should I change the
> > ambiguous method resolution code in PerlQt4 to handle this case, or is
> > it something that can be fixed in smoke?
> >
> > grep QByteArray::data smokedata.cpp
> >     {64, 7190, 0, 0, 0, 1692, 17},      //1927 QByteArray::data()
> >     {64, 7190, 0, 0, Smoke::mf_const, 2113, 18},        //1928
> > QByteArray::data() const
>
> This is done on purpose. There are some use cases, especially in QtDBus,
>  where you need the 'const' version of a method. Depending on whether the
>  method is const or not the returned value differs. Most of the time it
>  will suffice to simply call the non-const method, though.
>

The new generator might be correct, but the old one only generated the non-
const version. I think this is why Stefano found that the KSharedConfig::group
method no longer works:

a = KDE::Application.new
c = KDE::Global.config
Qt.debug_level = Qt::DebugLevel::Extensive
c.group 'xyz'

Gives:

candidate list:                                                                                                                
        KConfigGroup KConfigBase::group(const QString&)              (smoke: 1
index: 1969)                                    
        KConfigGroup KConfigBase::group(const char*)                 (smoke: 1
index: 1970)                                    
        const KConfigGroup KConfigBase::group(const QString&) const  (smoke: 1
index: 1972)                                    
        const KConfigGroup KConfigBase::group(const char*) const     (smoke: 1
index: 1973)        

And it now fails to resolve the method with the new generator's smoke lib.

I think that it is correct to have the two versions in the smoke library, and
leave it to the individual bindings to resolve between the two methods.

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