[rust-dev] Qt5 Rust bindings and general C++ to Rust bindings feedback
me at kevincantu.org
Fri Jun 6 02:35:01 PDT 2014
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." [
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?
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
>> Rust-dev mailing list
>> Rust-dev at mozilla.org
> Rust-dev mailing list
> Rust-dev at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rust-dev