tag:blogger.com,1999:blog-6454006.post1812514552451429928..comments2024-01-16T14:32:49.175+00:00Comments on Arcane Sentiment: Arbitrary overloading isn't always confusingArcane Sentimenthttp://www.blogger.com/profile/04144052171693893368noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-6454006.post-77092434765099324652012-04-29T21:09:08.640+00:002012-04-29T21:09:08.640+00:00In fact, integer / is not floor/, it is either flo...In fact, integer / is not floor/, it is either floor/ or truncate/, and you can't rely on arguments outside the intersection of these two functions.John Cowanhttps://www.blogger.com/profile/11452247999156925669noreply@blogger.comtag:blogger.com,1999:blog-6454006.post-35836533295682413252008-09-10T11:53:00.000+00:002008-09-10T11:53:00.000+00:00Another good example of arbitrary overloading used...Another good example of arbitrary overloading used correctly is in the Boost filesystem library where you can use / to concatenate paths. i.e.<BR/><BR/>newpath = path / filename;<BR/><BR/>and it will join the path and filename using the appropriate separator for the running OS.ferrucciohttps://www.blogger.com/profile/14320163540863400191noreply@blogger.comtag:blogger.com,1999:blog-6454006.post-88500066229843928052008-09-10T03:12:00.000+00:002008-09-10T03:12:00.000+00:00I find integer / as floor/ confusing too, especial...I find integer / as floor/ confusing too, especially since I'm used to languages that have correct division.<BR/><BR/>The confusion I get from arbitrary overloading isn't that I can't easily figure out the types of expressions, but that I can't recognize code at a glance so easily. Usually arithmetic looks different from string processing or I/O, largely because it uses different operations. So when I'm looking for a particular piece of code, I can filter out almost everything with only the most superficial reading, without considering types at all. Overloading can break this useful tool by making different sorts of code look more alike. It's not conscious confusion (except in annoying cases like Java string catenation) but a loss of obviousness.<BR/><BR/>The stereotypical of C++ iostream expressions makes them easy to recognize, which may be a reason their overloading isn't confusing.<BR/><BR/>I also worry about overloading interfering with extensibility, e.g. in an autoconverting language you can't catenate numbers because they get added instead, or with error detection, because adding strings isn't an error. I'm not sure I've encountered either of these, though.<BR/><BR/>The C++ evaluation order example doesn't have anything to do with overloading, does it?Arcane Sentimenthttps://www.blogger.com/profile/04144052171693893368noreply@blogger.comtag:blogger.com,1999:blog-6454006.post-41745178326229877842008-09-09T12:24:00.000+00:002008-09-09T12:24:00.000+00:00Counter-example for C++ I/O: http://barrkel.blogsp...Counter-example for C++ I/O: <A HREF="http://barrkel.blogspot.com/2008/04/c-evaluation-order-gotcha.html" REL="nofollow">http://barrkel.blogspot.com/2008/04/c-evaluation-order-gotcha.html</A><BR/><BR/>For my part, I've never been confused, or even ever surprised, by + overloaded for addition versus concatenation. On the other hand, I have been surprised by / as used for integer division in C (but not, of course, in Pascal, which I had learned previously).<BR/><BR/>There's probably at least two things going on here. First, how adept you are as a programmer at recognizing the type of any given <B>subexpression</B> (i.e. not just a factor) and thus your degree of certainty as to the selected overload of any given operator; and secondly, the knowledge of the operators themselves, as they apply to values of different types.<BR/><BR/>The first skill takes some time to learn, as one gets used to the evaluation order etc. I think the skill is built up more quickly in a statically and strongly typed language. I would strongly suspect that a weakly and dynamically typed language, e.g. one which coerces strings like "42" to integers like 42 depending on the operator, would be the corresponding worst-case scenario for learning this.<BR/><BR/>On the operators, I think this has to do with one's preconceived notions of what effect each operator has on values of a particular type, if any. If you don't have a prior notion, it's very easy to learn, like C++ streams. If you do have prior notions, like different '/' overloads having particular return types, you'll be more likely to be tripped up.<BR/><BR/>So, in the specific case of '+', I would expect dynamically-typed and strongly type-inferred language users to be more easily tripped up. Lack of type annotations and reliance on invariants that are in the programmer's mind, rather than in the program text, would probably lead to less accuracy in knowing subexpression types. The static type system should warn the programmer earlier, though.<BR/><BR/>That '+' relates to such different operations as addition and concatenation, I think is a lesser problem; I think '/' as integer division and floating-point division should cause an equivalent amount of mistakes, assuming that the programmer doesn't have prior notions of either (i.e. knows all the overloads of '+' and '/' to an equivalent level).<BR/><BR/>Finally, one last thing about stream operators: these have a specific idiom. Stream on extreme left, then a '>>' or '<<' separated list of things to extract or insert. The fact that they don't usually appear in arbitrary subexpressions is another strong indicator, to me, that the "operators" need scarcely even be recognized as such. The insertion / extraction idiom looks like a statement, not an expression.Barry Kellyhttps://www.blogger.com/profile/10559947643606684495noreply@blogger.com