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 <[email protected]> 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 <[email protected]> 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 < >> [email protected]> wrote: >> >>> >>> >>> >>> On Sat, May 24, 2014 at 9:06 AM, Zoltán Tóth <[email protected]> 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 >>>>> [email protected] >>>>> https://mail.mozilla.org/listinfo/rust-dev >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Rust-dev mailing list >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/rust-dev >>>> >>>> >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/rust-dev >>> >>> >> >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
