Overloading

[Ayende Rahien]

How does it heavily complicate a lanaguage that already supports
overloading.

You are the compiler, given this scenario, which will you choose?

methods:
object Test();
string Test();
int Test();
Derived Test();
code calling method:
Test();
string Testing = Test();
Base Testin2 = Test();

How do you choose? How do you avoid complications when you *don't* do it.
IE, force to do something like this:
(string)Test();
when you've only one type of Test() method.

Compilers have enough problems with ambiguity on those things:
void Test(int);
void Test(long);

Test(1);//??? Which do you call ???

Dont be stupid. Tard

Don't be rude, either.

 

[Alvin Bruney]

Isn't there ambiguity in overloading as it stands today?

public Int32 BlahFn(Control c)

public Int32 BlahFn(Button b)


If it can resolve that, then it can do the same with return type
overloading.

Other languages can manage it, so I am sure C# can also if they banged
theyre developers heads off the wall a few times.

 

[Alvin Bruney]

If there is ambiguity on the return type (like when they do not specify a
return) then they should get a compiler error stating they must use a return
to allow it to determine which one to call.

Not hard at all.

I would rather have return overloading then have to specify a different
method for someting that is more natural as an overload.

The runtime can support this, its the language that has the limitation that
I would like to see added.

 

[Daniel O'Connell]

If there is ambiguity on the return type (like when they do not specify a
return) then they should get a compiler error stating they must use a return
to allow it to determine which one to call.

Not hard at all.

I would rather have return overloading then have to specify a different
method for someting that is more natural as an overload.

As would I, I just don't think its possible without making the language
unpleasent. If the language EVER forces me to accept a return type, I'm
leaving the language behind, at that point its become too full of itself.
I'd rather see call syntax that specifies return type(as IL does) rather
than implicit type resolution.
I don't want to have tow rite code like this:
Object o;
String s;
s = Method();
o = s;

just because of return type overloading. Its unpleasent and *decreases*
productivity.

The runtime can support this, its the language that has the limitation that
I would like to see added.

Why not grab rotor and add it yourself...see how it works. If you get it
going good submit a proposal to Microsoft and the ECMA.

 

[Daniel O'Connell]

Isn't there ambiguity in overloading as it stands today?

public Int32 BlahFn(Control c)

public Int32 BlahFn(Button b)


If it can resolve that, then it can do the same with return type
overloading.

It can, its not perfect however. In the case of parameters the user HAS to
specify the parameter, as the language stands today return types can be
ignored.

Other languages can manage it, so I am sure C# can also if they banged
theyre developers heads off the wall a few times.

I'm sure they could, but would it be a good thing? At the very least call
syntax would have to exist to provide explicit overload calling instead of
implicit guessing(Ideally the compiler would require return type
specification instead of forcing accepting the return in clashing cases). It
is also not a feature in the CLS and would probably require you to provide
less natural second methods to support VB and C++, for example.

There are other things I'd consider more important to implement, however,
like Eiffels Design by Contract or a more powerful component contracting
mechanism(which would specify the contract rules within itself, ideally).

More importantly, what does the rest of the community think? Out of everyone
who's posted here, only the two of us have mentioned that yes, return tyupe
overloading would be useful. I'm only aganst it as a purely implicit thing,
as an explicit specification it could be acceptable.

 

[Guest]

What if we limit this to value types and not reference types?

No inheritence worries.

 

[Daniel O'Connell]

What if we limit this to value types and not reference types?

No inheritence worries.

Then why bother putting it in if its that limited? It would only clear up a
small set of cases while applying an artificial boundary, and it still
wouldn't clear up the need for language syntax to specify which overload to
call.

 

[Daniel O'Connell]

Then why bother putting it in if its that limited? It would only clear up a
small set of cases while applying an artificial boundary, and it still
wouldn't clear up the need for language syntax to specify which overload to
call.

And, might I add, not support what the runtime is capable of supporting,
AFAIK anway.

 

[Krishnan]

Hi Alvin,
Am sorry, but I beg to differ from you. A function overload is defined as a
scenario wherein "More than one function use the same function name, but
with different function signatures".

And a signature:
Function signature includes argument types and number, and const status of
function. (Return type is not part of the signature).

Hence, we can say that, by definition, functions with "only" different
return types cannot be overloaded. For further reading, please go thorugh
the following PDF:
(Please note that the definitons given here extend beyond the realm of C++
and cover the gamut of OO programming.)

course.ie.cuhk.edu.hk/~ieg7003/ lectures/cpp_bas_1pp.pdf

Thanks
Krishnan
Codito Ergo Sum

 

[Jon Skeet [C# MVP]]

Am sorry, but I beg to differ from you. A function overload is defined as a
scenario wherein "More than one function use the same function name, but
with different function signatures".

And a signature:
Function signature includes argument types and number, and const status of
function. (Return type is not part of the signature).

Hence, we can say that, by definition, functions with "only" different
return types cannot be overloaded. For further reading, please go thorugh
the following PDF:
(Please note that the definitons given here extend beyond the realm of C++
and cover the gamut of OO programming.)

course.ie.cuhk.edu.hk/~ieg7003/ lectures/cpp_bas_1pp.pdf

Well, no, the definitions given *are* specific to C++ - they happen to
coincide with the definitions of signature for many other languages,
but that doesn't make them globally OO definitions.

ECMA 335 clearly specifies that in .NET itself, the return type *is*
part of a method signature.

That doesn't mean that I support the idea of overloading purely by
differing return type in C#, but the claim that method signatures never
include return types just isn't true.

 

[Krishnan]

Thanks John.
yeah u r dead right, but ECMA also says:
CLS Rule 38: Properties, instance methods, and virtual methods may be
overloaded based *only* on the number
and types of their parameters, except the conversion operators named
op_Implicit and op_Explicit which may
also be overloaded based on their return type.
(p-72 Sec-10.2)

Does that put an end to this seeming confusion over overloads?

Krishnan

 

[Jon Skeet [C# MVP]]

yeah u r dead right, but ECMA also says:
CLS Rule 38: Properties, instance methods, and virtual methods may be
overloaded based *only* on the number
and types of their parameters, except the conversion operators named
op_Implicit and op_Explicit which may
also be overloaded based on their return type.
(p-72 Sec-10.2)

Does that put an end to this seeming confusion over overloads?

Not quite - because as you say, that's a CLS rule - it's not a CLR
rule. Non-CLS-compliant types could overload on return types.
Presumably the reason for the CLS rule is that most languages would
have a tough time with types which *did* overload purely based on
return type.