Gustavo Carneiro <gjcarne...@gmail.com> writes: > Don't you think that when these overloading problems become an issue it is a > sign of a poorly designed API?
In this case the intention is to fix bugs in boost.python. The broken example we've been working with is where a parameter is bool in one overload and int in another. Does this indicate a broken API? That's above my pay grade... I'm willing to say "probably not in all cases". > I mean, if overloaded functions parameters are not completely > different in type or number, then maybe they are already too confusing > to use and should not be overloaded in the first place?... Maybe yes, though to my mind the real issue is an aesthetic one: should one at all attempt to emulate overloading in a language that doesn't have it natively? A similar discussion ensues w.r.t. "const". I wasn't around when the feature was added, which was ~7 years ago; to remove overloading now would break lots of code, and that decides it. So I'd phrase it like this: let's fix what's there so long as the cost in runtime and complexity is sufficiently small. -t _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
