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
