7

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?

northTiger
  • 255
  • 1
  • 2
  • 5
  • 1
    I would start at [Eric Lippert's](http://blogs.msdn.com/b/ericlippert/archive/tags/overload+resolution/) blog. There are 8 posts marked taged with **overload resolution**. – Roman May 29 '10 at 03:36
  • Why do you need an example? In Java you can easily replace a function in a subclass, in C# you mark the function as virtual, then can override it. – James Black May 29 '10 at 03:37
  • @R0MANARMY: That's the correct answer to this question. If you post it as an answer, I will upvote it. – Robert Harvey May 29 '10 at 03:37
  • 4
    @James: That is *overriding*, not *overloading*. – Adam Robinson May 29 '10 at 03:38
  • @james, I am talking about overloading instead of overriding. – northTiger May 29 '10 at 03:39
  • 1
    @Robert Harvey: I feel like that's kind of a half-assed answer. There are quite a few people on SO that could answer the question in much better detail than "read X." Content of said answers would also be more valuable to SO. – Roman May 29 '10 at 03:41

2 Answers2

19

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

Link

and for more thoughts on overload resolution, see

Link

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
Eric Lippert
  • 647,829
  • 179
  • 1,238
  • 2,067
  • 2
    Do you get paged whenever your name is mentioned in a question to make sure it's answered regardless of time of day ;) ? – Roman May 29 '10 at 07:33
  • C++ automatically hides all functions with the same name, if one is defined in a more derived class. So unless you use a "using base::functionname" declaration (which "unhides" the name again), the effect is similar. It's not exactly the same though, because in C++ those hidden names will not be considered at all, even if no overload in the more derived class is applicable. It serves the same prupose though - new functions in base classes will not be called unintentionally. – Paul Groke Dec 23 '12 at 18:34
1

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.

Robert Harvey
  • 178,213
  • 47
  • 333
  • 501
  • Well....that explains his [other question](http://stackoverflow.com/questions/2926470/c-language-design-pillars). – Roman May 29 '10 at 03:45