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 in message
news:uPu7uHaWFHA.2768@xxxxxxxxxxxxxxxxxxxxxxx
> "Daniel O'Connell [C# MVP]" <onyxkirx@xxxxxxxxxxxxxxxxxxxxx> wrote in
> message news:%23le$D74VFHA.3184@xxxxxxxxxxxxxxxxxxxxxxx
>> Now, you add into that a requirement to know the type of the variable the
>> return type is going to be assigned to or the parameter type it will be
>> passed to. This forces the compiler to have to be able to see
>>
>> int x = Parse(something);
>
> The compiler is going to need to know the return type anyway. I don't see
> it much different from:
>
> Parse(Something, ref x);

Why would you see it as that? The two are semantically different.

Anyway, yes the compiler already knows the return type, but it is capable fo
determing the return type from the method call alone. To overload on return
type would require more information than the method call alone can provide.

>
>> The method call is not individually resolvable, it becomes an expression
>> that means nothing concrete without being contained within another
>> expression(I do not believe this issue exists *anywhere* else in the
>> language, but I'm not certain). The compiler is harder to write, the
>> language harder to learn. Bam, instant complexity at the base level of
>> the compiler.
>
> Overloading makes the language harder to learn, as does inheritance and
> interfaces, we'd better leave those out too. :-)
>

You realize, everyone uses this argument for everything. This is as
effective of a reason for insisting that the language must require case to
change for every letter of an identifier as it is for this.

As Steve Walker points out, its utility verse complexity. Inheritance and
interfaces offer significant utility with moderate complexity whereas return
type overloading provides minimal utliity with significant complexity.


>> Given:
>> int Parse(string value);
>> double Parse(string value);
>>
>> int Calc(int value);
>> double Calc(double value);
>>
>> double d = Calc(Parse("15")):
>>
>> When the compiler takes a look at the call to Parse it cannot resolve
>> what overload to call. The compile rmust then take a look at the
>> parameter type for Calc, which also cannot be resolved atomicall ywithout
>> knowing the resolved return type of the Parse call, so you have yet
>> another unresolved method. You step back a little farther and finally
>> discover an assignment meaning you can determine the desired return type
>> of Calc, and in this example, determine which overload of Parse must be
>> called. However, considering the compiler without return type overloads
>> would have had no trouble doing this, what is the cost in complexity?
>
> But it can do it and it makes sense to the programmer for it to be double
> all the way through.
>

It does? To me it doesn't in *ANY* way tell me that Parse() should be
returnign a double without knowing that the specific Calc method is tied to
the type of the return type. I don't think that is clear in any way. That is
like saying that I can tell from a baby what its grandfather looks like.
Sure, its possible, but its a shot in the dark unless you already know the
answer.

And,then, what does something like

this.Property = Calc(Parse(GetString()))

mean? The type is hidden and all three method calls are terribly ambigious
from the programmers point of view.

Let me ask you this, have you *ever* used an OO langauge that allows return
type overloading, especially one that determines the method to call
automatically?

>> Is this really as simple as you think it is? I've not even started on the
>> possible issues with generics and anonymous methods and the language
>> itself is already considerably more complex. Realistically implementing
>> return type overloading, IMHO, requires a mechanism to manually select
>> the override instead of relying on automatic selection that ignores casts
>> and converstions.
>
> I'm sure it can get complex but in any case it can't resolve the call it
> should just say so. Programmers would know to specify the return type in
> the necessary cases. Maybe something like double d =
> Calc((double)Parse("15")): could be used.
>

Yet that is ambigious at best, what do you do when you end up needing code
you can't write because the compiler cannot resolve what you are doing?

And, more importantly, *WHY* is all this better than just DoubleFromString()
and IntFromSTring() ?


.

Relevant Pages

  • Re: Why cant overloads take into account the return type.
    ... The compiler is going to need to know the return type anyway. ... instant complexity at the base level of the ... > impossible to resolve scenarios. ... > return type overloading, IMHO, requires a mechanism to manually select the ...
    (microsoft.public.dotnet.languages.csharp)
  • OO and information oriented programming (was Re: Simple Parser)
    ... >> If you're developing a compiler for a language for the first time, ... >> the grammar you're using does what you want, ... Computers don't just process for the sake of it. ... reducing complexity, a task at the core of software development. ...
    (comp.programming)
  • Re: OO and information oriented programming (was Re: Simple Parser)
    ... > The parse tree tells the developer a lot about the behaviour of a part of ... The first version of the Basic compiler for my book "Design Your Own ... > Computers don't just process for the sake of it. ... > reducing complexity, a task at the core of software development. ...
    (comp.programming)
  • Re: C needs a BOOST
    ... KT>but it's not obvious that the implicit code for ordinary ... You now that the compiler will just reserve some space for the variable ... You dig through the C++ file and all the included header files to find the ... Then you try to estimate the complexity of the constructor and go ...
    (comp.std.c)
  • Re: ?PAIRS
    ... Control Structures with Compiler Security" by Marc Perkel. ... RESOLVE Resolves forward branch and leaves a gap. ... on the stack was indeed left by>MARK. ... they figure the zero could have been left by>MARK. ...
    (comp.lang.forth)