[rust-dev] Qt5 Rust bindings and general C++ to Rust bindings feedback

Kevin Cantu me at kevincantu.org
Fri Jun 6 02:54:17 PDT 2014


Apologies for the accidentally sent email.  Not sure what GMail just did
for me there.  Anyways, with a macro it should be possible to use the types
given to choose between mangled names, for example, at compile time.

Kevin







On Fri, Jun 6, 2014 at 2:44 AM, Kevin Cantu <me at kevincantu.org> wrote:

> I imagine a macro like the following, which is NOT a macro, because I
> don't know how to write macros yet:
>
>
> macro fillRect(args...) {
>
> fillRect_RF_B ( const QRectF & rectangle, const QBrush & brush )
> fillRect_I_I_I_I_BS ( int x, int y, int width, int height, Qt::BrushStyle
> style )
> fillRect_Q_BS ( const QRect & rectangle, Qt::BrushStyle style )
> fillRect_RF_BS ( const QRectF & rectangle, Qt::BrushStyle style )
> fillRect_R_B ( const QRect & rectangle, const QBrush & brush )
> fillRect_R_C ( const QRect & rectangle, const QColor & color )
> fillRect_RF_C ( const QRectF & rectangle, const QColor & color )
> fillRect_I_I_I_I_B ( int x, int y, int width, int height, const QBrush &
> brush )
> fillRect_I_I_I_I_C ( int x, int y, int width, int height, const QColor &
> color )
> fillRect_I_I_I_I_GC ( int x, int y, int width, int height, Qt::GlobalColor
> color )
> fillRect_R_GC ( const QRect & rectangle, Qt::GlobalColor color )
> fillRect_RF_GC ( const QRectF & rectangle, Qt::GlobalColor color )
>
>
>
>
>
>
>
>
> On Fri, Jun 6, 2014 at 2:35 AM, Kevin Cantu <me at kevincantu.org> wrote:
>
>> Since C# allows overloaded methods, but F# doesn't want them, what F#
>> does is somewhat interesting: "overloaded methods are permitted in the
>> language, provided that the arguments are in tuple form, not curried form."
>> [http://msdn.microsoft.com/en-us/library/dd483468.aspx]
>>
>> In practice, this means that all the calls to C# (tupled arguments) can
>> be resolved, but idiomatic F# doesn't have overloaded methods.
>>
>> // tuple calling convention: looks like C#
>> let aa = csharp_library.mx(1, 2)
>> let bb = csharp_library.mx(1)
>>
>> // curried calling convention: makes dd, below, a function not a value
>> let cc = fsharp_library.m2 1 2
>> let dd = fsharp_library.m2 1
>>
>> Would it be useful to use pattern matching over some generic sort of
>> tuples to implement something similar in Rust?
>>
>>
>> Kevin
>>
>>
>>
>> On Sat, May 24, 2014 at 3:45 AM, Matthieu Monrocq <
>> matthieu.monrocq at gmail.com> wrote:
>>
>>>
>>>
>>>
>>> On Sat, May 24, 2014 at 9:06 AM, Zoltán Tóth <zo1980 at gmail.com> wrote:
>>>
>>>> Alexander, your option 2 could be done automatically. By appending
>>>> postfixes to the overloaded name depending on the parameter types.
>>>> Increasing the number of letters used till the ambiguity is fully resolved.
>>>>
>>>> What do you think?
>>>>
>>>>
>>>> fillRect_RF_B ( const QRectF & rectangle, const QBrush & brush )
>>>> fillRect_I_I_I_I_BS ( int x, int y, int width, int height,
>>>> Qt::BrushStyle style )
>>>> fillRect_Q_BS ( const QRect & rectangle, Qt::BrushStyle style )
>>>> fillRect_RF_BS ( const QRectF & rectangle, Qt::BrushStyle style )
>>>> fillRect_R_B ( const QRect & rectangle, const QBrush & brush )
>>>> fillRect_R_C ( const QRect & rectangle, const QColor & color )
>>>> fillRect_RF_C ( const QRectF & rectangle, const QColor & color )
>>>> fillRect_I_I_I_I_B ( int x, int y, int width, int height, const QBrush
>>>> & brush )
>>>> fillRect_I_I_I_I_C ( int x, int y, int width, int height, const QColor
>>>> & color )
>>>> fillRect_I_I_I_I_GC ( int x, int y, int width, int height,
>>>> Qt::GlobalColor color )
>>>> fillRect_R_GC ( const QRect & rectangle, Qt::GlobalColor color )
>>>> fillRect_RF_GC ( const QRectF & rectangle, Qt::GlobalColor color )
>>>>
>>>>
>>>> I believe this alternative was considered in the original blog post
>>> Alexander wrote: this is, in essence, mangling. It makes for ugly function
>>> names, although the prefix helps in locating them I guess.
>>>
>>>
>>> Before we talk about generation though, I would start about
>>> investigating where those overloads come from.
>>>
>>> First, there are two different objects being manipulated here:
>>>
>>> + QRect is a rectangle with integral coordinates
>>> + QRectF is a rectangle with floating point coordinates
>>>
>>>
>>> Second, a QRect may already be build from "(int* x*, int* y*, int*
>>> width*, int* height*)"; thus all overloads taking 4 hints instead of a
>>> QRect are pretty useless in a sense.
>>>
>>> Third, in a similar vein, QBrush can be build from "(Qt::BrushStyle)",
>>> "(Qt::GlobalColor)" or "(QColor const&)". So once again those overloads are
>>> pretty useless.
>>>
>>>
>>> This leaves us with:
>>>
>>> + fillRect(QRect const&, QBrush const&)
>>> + fillRect(QRectF const&, QBrush const&)
>>>
>>> Yep, that's it. Of all those inconsistent overloads (missing 4 taking 4
>>> floats, by the way...) only 2 are ever useful. The other 10 can be safely
>>> discarded without impacting the expressiveness.
>>>
>>>
>>> Now, of course, the real question is how well a tool could perform this
>>> reduction step. I would note here that the position and names of the
>>> "coordinate" arguments of "fillRect" is exactly that of those to "QRect";
>>> maybe a simple exhaustive search would thus suffice (though it does require
>>> semantic understanding of what a constructor and default arguments are).
>>>
>>> It would be interesting checking how many overloads remain *after* this
>>> reduction step. Here we got a factor of 6 already (should have been 8 if
>>> the interface had been complete).
>>>
>>> It would also be interesting checking if the distinction int/float often
>>> surfaces, there might be an opportunity here.
>>>
>>>
>>> -- Matthieu
>>>
>>>
>>> Alexander Tsvyashchenko wrote:
>>>>
>>>>>  So far I can imagine several possible answers:
>>>>>
>>>>>    1. "We don't care, your legacy C++ libraries are bad and you
>>>>>    should feel bad!" - I think this stance would be bad for Rust and would
>>>>>    hinder its adoption, but if that's the ultimate answer - I'd personally
>>>>>    prefer it said loud and clear, so that at least nobody has any illusions.
>>>>>
>>>>>    2. "Define & maintain the mapping between C++ and Rust function
>>>>>    names" (I assume this is what you're alluding to with "define meaningful
>>>>>    unique function names" above?) While this might be possible for smaller
>>>>>    libraries, this is out of the question for large libraries like Qt5 - at
>>>>>    least I won't create and maintain this mapping for sure, and I doubt others
>>>>>    will: just looking at the stats from 3 Qt5 libraries (QtCore, QtGui and
>>>>>    QtWidgets) out of ~30 Qt libraries in total, from the 50745 wrapped
>>>>>    methods 9601 were overloads and required renaming.
>>>>>
>>>>>    Besides that, this has a disadvantage of throwing away majority of
>>>>>    the experience people have with particular library and forcing them to
>>>>>    le-learn its API.
>>>>>
>>>>>    On top of that, not for every overload it's easy to come up with
>>>>>    short, meaningful, memorable and distinctive names - you can try that
>>>>>    exercise for
>>>>>    http://qt-project.org/doc/qt-4.8/qpainter.html#fillRect ;-)
>>>>>
>>>>>    3. "Come up with some way to allow overloading / default
>>>>>    parameters" - possibly with reduced feature set, i.e. if type inference is
>>>>>    difficult in the presence of overloads, as suggested in some overloads
>>>>>    discussions (although not unsolvable, as proven by other languages that
>>>>>    allow both type inference & overloading?), possibly exclude overloads from
>>>>>    the type inference by annotating overloaded methods with special attributes?
>>>>>
>>>>>    4. Possibly some other options I'm missing?
>>>>>
>>>>>  --
>>>>> Good luck!                                     Alexander
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Rust-dev mailing list
>>>>> Rust-dev at mozilla.org
>>>>> https://mail.mozilla.org/listinfo/rust-dev
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Rust-dev mailing list
>>>> Rust-dev at mozilla.org
>>>> https://mail.mozilla.org/listinfo/rust-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Rust-dev mailing list
>>> Rust-dev at mozilla.org
>>> https://mail.mozilla.org/listinfo/rust-dev
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140606/52a93c00/attachment.html>


More information about the Rust-dev mailing list