Reputation: 253
From the article Anders Hejsberg interview, "the way we do overload resolution in C# is different from any other language" Can somebody provide some examples with C# and Java?
Upvotes: 7
Views: 1271
Reputation: 660523
What Anders was getting at here was that the original design team explicitly designed the overload resolution algorithm to have certain properties that worked nicely with versioning scenarios, even though those properties seem backwards or confusing when you consider the scenarios without versioning.
Probably the most common example of that is the rule in C# that if any method on a more-derived class is an applicable candidate, it is automatically better than any method on a less-derived class, even if the less-derived method has a better signature match. This rule is not, to my knowledge, found in other languages that have overload resolution. It seems counterintuitive; if there's a method that is a better signature match, why not choose it? The reason is because the method that is a better signature match might have been added in a later version and thereby be introducing a "brittle base class" failure.
For more thoughts on how various languages handle brittle base class failures, see
and for more thoughts on overload resolution, see
Upvotes: 19
Reputation: 180918
The way that C# handles overloading from an internal perspective is what's different.
The complete quote from Anders:
I have always described myself as a pragmatic guy. It's funny, because versioning ended up being one of the pillars of our language design. It shows up in how you override virtual methods in C#. Also, the way we do overload resolution in C# is different from any other language I know of, for reasons of versioning. Whenever we looked at designing a particular feature, we would always cross check with versioning. We would ask, "How does versioning change this? How does this function from a versioning perspective?" It turns out that most language design before has given very little thought to that.
Upvotes: 1