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