Re: Why can't overloads take into account the return type.

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Michael C <mculley@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> "Jon Skeet [C# MVP]" <skeet@xxxxxxxxx> wrote in message
> news:MPG.1cf248cf4c9d689698c119@xxxxxxxxxxxxxxxxxxxxxxx
> > Out of interest, why do you think that is? You're not the first person
> > to come up with this idea, so if it's such a good idea, why do you
> > think it hasn't made it into any languages?
>
> For some reason language writers seem to like to keep things consistant with
> previous languages.

Given how many experimental languages there are, that seems unlikely to
me. There are plenty of languages which try lots of different things,
and the best concepts usually work their way into the mainstream
eventually. I think there's a good reason for overloading by return
type not making it - it adds too much complexity for too little
benefit.

> > While I can see it would allow us to get away from having lots of
> > methods with different names but the same parameter types, that's the
> > *only* advantage I can see,
>
> That's the only advantage of the current overloads.

The difference is how often that's useful compared with how often
overloading by return type would be useful though. Look at all the
examples of overloading by parameters in the framework, and then think
of how many places overloading by return type would really be useful.
Places I can think of:

DataReader
Convert
BitConverter
Stream
TextReader
BinaryReader
Marshal

Frankly, in all those places I think having the instantly readable an
unambiguous calls is often more of a blessing than a curse. Arguably
having more explicit alternatives to overloading for writing in some of
the above would be a better way to improve things - and at no language
complexity cost.

> > and that situation comes up pretty rarely
> > in my experience. I don't think it justitifies making the language
> > significantly more complicated.
>
> I don't see it as much greater complexity. For example if they'd
> implemeneted it for the datareader you might have to write it as
> (int)reader.Value(1) instead of reader.GetInt(1). If the compiler complained
> in any situation that was not dead obvious then it could work quite well.

It's a fundamentally more complicated language though, as the type of
an expression would depend on its context in a way in which it simply
doesn't now.

--
Jon Skeet - <skeet@xxxxxxxxx>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
.

Relevant Pages

  • Re: Confessions of an "OO Foreigner"
    ... In other areas and other languages it HAS fulfilled ... Cobol already had solutions to ... > expression operators to be methods, also with overloading. ...
    (comp.lang.cobol)
  • Re: whats it worth to write a short program for polynomial multiplication?
    ... But this is the fault of the languages; ... Sparse polynomials and dense polynomials should be ... but he did not try overloading. ... (dolist (i L1 ans) ...
    (sci.math.symbolic)
  • Re: Parentheses in function calls
    ... Below I have asked for clarification at various points. ... arguments by parentheses, or not use parentheses at all. ... different languages. ... allow operator overloading where a user-defined function is "hidden" ...
    (comp.lang.c)
  • Re: Delphi 7/8 Language enhancements
    ... They are part of the ECMA docs about the CLI. ... Shall not publicly expose overloading except as ... Object-Oriented languages, do not support ... support neither operator overloading nor overloading based on return ...
    (borland.public.delphi.non-technical)
  • Re: Why is OO Popular?
    ... it's a far worse mess than bad procedural code. ... There are natural complexities to object languages, ... > mathematics and say the languages are bad for doing so. ... they mix value and variable semantics adds complexity, ...
    (comp.object)