By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,152 Members | 1,647 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,152 IT Pros & Developers. It's quick & easy.

Overloading

P: n/a
Hi,

Why can I not overload on just the return type?

Say for example.

public int blah(int x)
{
}

and

public double blah(int x)
{
}
Why not, seems quite straight forward to me, why is this a limitation on C#?
Nov 15 '05 #1
Share this Question
Share on Google+
31 Replies


P: n/a
This is not a limitation of C#, it's not possible in VB.NET too, so I think
it's a IL/CLR limitation. In my opinion it wouldn't make sense to overload a
method only by it's return type. For example, lets say you have an
overloaded method TestMe that returns either a string value or a long value:

string s = TestMe(); ///This is quite straight-forward
object o = TestMe(); ///Would be a problem.
--
Greetz

Jan Tielens
________________________________
Read my weblog: http://weblogs.asp.net/jan

<di********@discussion.microsoft.com> wrote in message
news:O0**************@TK2MSFTNGP09.phx.gbl...
Hi,

Why can I not overload on just the return type?

Say for example.

public int blah(int x)
{
}

and

public double blah(int x)
{
}
Why not, seems quite straight forward to me, why is this a limitation on C#?

Nov 15 '05 #2

P: n/a
<di********@discussion.microsoft.com> wrote:
Why can I not overload on just the return type?

Say for example.

public int blah(int x)
{
}

and

public double blah(int x)
{
}
Why not, seems quite straight forward to me, why is this a limitation on C#?


Which version would get called here:

blah(5);

?

Or how about:

Console.WriteLine (blah(5));

?

Basically, it introduces an awful lot of ambiguity - and ends up with
an expression without a specific type, which doesn't occur anywhere
else in the language.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #3

P: n/a
Good Q in fact.
Lemme take a shot at it:
As I understand, while a function *prototype* describes the return type and
parameters, a function signature *does not include* return types. And
functiona overloading *defines* only functions of different signatures can
be overloaded.
Please correct me if am wrong here.

TIA
Krishnan
<di********@discussion.microsoft.com> wrote in message
news:O0**************@TK2MSFTNGP09.phx.gbl...
Hi,

Why can I not overload on just the return type?

Say for example.

public int blah(int x)
{
}

and

public double blah(int x)
{
}
Why not, seems quite straight forward to me, why is this a limitation on C#?

Nov 15 '05 #4

P: n/a
No, threre's no such restriction at the IL level, but other managed MSFT
languages choose not to support it.

Willy.

"Jan Tielens" <ja*@no.spam.please.leadit.be> wrote in message
news:ul**************@TK2MSFTNGP11.phx.gbl...
This is not a limitation of C#, it's not possible in VB.NET too, so I think it's a IL/CLR limitation. In my opinion it wouldn't make sense to overload a method only by it's return type. For example, lets say you have an
overloaded method TestMe that returns either a string value or a long value:
string s = TestMe(); ///This is quite straight-forward
object o = TestMe(); ///Would be a problem.
--
Greetz

Jan Tielens
________________________________
Read my weblog: http://weblogs.asp.net/jan

<di********@discussion.microsoft.com> wrote in message
news:O0**************@TK2MSFTNGP09.phx.gbl...
Hi,

Why can I not overload on just the return type?

Say for example.

public int blah(int x)
{
}

and

public double blah(int x)
{
}
Why not, seems quite straight forward to me, why is this a limitation on

C#?


Nov 15 '05 #5

P: n/a

<di********@discussion.microsoft.com> wrote in message
news:O0**************@TK2MSFTNGP09.phx.gbl...
Hi,

Why can I not overload on just the return type?


I believe Eiffel supports this
Nov 15 '05 #6

P: n/a
True, and ILASM also, here's a sample (compile with ilasm).

..assembly extern mscorlib
{
.publickeytoken = (B7 7A 5C 56 19 34 E0 89 )
.ver 1:0:5000:0
}

..assembly invaril
{
.hash algorithm 0x00008004
.ver 0:0:0:1
}

..class private Invariant
{
.method public specialname
instance void .ctor()
{
ret
}

.method public instance int32 Foo()
{
.locals init (int32 local0)
ldc.i4.1
ret //return 1
}

.method public instance int64 Foo()
{
.locals init (int64 local0)
ldc.i4.2
conv.i8
ret // return 2
}
}

..method public static void Execute()
{
.entrypoint
.locals init (class Invariant local0)
newobj instance void Invariant::.ctor()
stloc.0
ldloc.0
//Call int32::Foo()
callvirt instance int32 Invariant::Foo()
call void [mscorlib]System.Console::WriteLine(int32)
ldloc.0
// Call int64::Foo()
callvirt instance int64 Invariant::Foo()
call void [mscorlib]System.Console::WriteLine(int64)
ret
}
Willy.

"andrew lowe" <andrew dot lowe at geac dot com> wrote in message
news:uU**************@tk2msftngp13.phx.gbl...

<di********@discussion.microsoft.com> wrote in message
news:O0**************@TK2MSFTNGP09.phx.gbl...
Hi,

Why can I not overload on just the return type?


I believe Eiffel supports this

Nov 15 '05 #7

P: n/a
It SHOULD be supported as its technically a DIFFERENT function signiture.

I think its stupid not to support this. Is there any valid reason why this
is not implemented?

I cant think of one.

"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message
news:ub**************@TK2MSFTNGP11.phx.gbl...
True, and ILASM also, here's a sample (compile with ilasm).

.assembly extern mscorlib
{
.publickeytoken = (B7 7A 5C 56 19 34 E0 89 )
.ver 1:0:5000:0
}

.assembly invaril
{
.hash algorithm 0x00008004
.ver 0:0:0:1
}

.class private Invariant
{
.method public specialname
instance void .ctor()
{
ret
}

.method public instance int32 Foo()
{
.locals init (int32 local0)
ldc.i4.1
ret //return 1
}

.method public instance int64 Foo()
{
.locals init (int64 local0)
ldc.i4.2
conv.i8
ret // return 2
}
}

.method public static void Execute()
{
.entrypoint
.locals init (class Invariant local0)
newobj instance void Invariant::.ctor()
stloc.0
ldloc.0
//Call int32::Foo()
callvirt instance int32 Invariant::Foo()
call void [mscorlib]System.Console::WriteLine(int32)
ldloc.0
// Call int64::Foo()
callvirt instance int64 Invariant::Foo()
call void [mscorlib]System.Console::WriteLine(int64)
ret
}
Willy.

"andrew lowe" <andrew dot lowe at geac dot com> wrote in message
news:uU**************@tk2msftngp13.phx.gbl...

<di********@discussion.microsoft.com> wrote in message
news:O0**************@TK2MSFTNGP09.phx.gbl...
Hi,

Why can I not overload on just the return type?


I believe Eiffel supports this


Nov 15 '05 #8

P: n/a

"Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
news:O6**************@TK2MSFTNGP11.phx.gbl...
It SHOULD be supported as its technically a DIFFERENT function signiture.

I think its stupid not to support this. Is there any valid reason why this
is not implemented?

I cant think of one.

Its pretty simple, it heavily complicates the language for very little
benifit. I don't care to have to specify return type on every call, doubt
you would either. Even with defaults it is a messy situation.
Do you have a suggestion as to how to implement it without causing a major
complexity increase?
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message
news:ub**************@TK2MSFTNGP11.phx.gbl...
True, and ILASM also, here's a sample (compile with ilasm).

.assembly extern mscorlib
{
.publickeytoken = (B7 7A 5C 56 19 34 E0 89 )
.ver 1:0:5000:0
}

.assembly invaril
{
.hash algorithm 0x00008004
.ver 0:0:0:1
}

.class private Invariant
{
.method public specialname
instance void .ctor()
{
ret
}

.method public instance int32 Foo()
{
.locals init (int32 local0)
ldc.i4.1
ret //return 1
}

.method public instance int64 Foo()
{
.locals init (int64 local0)
ldc.i4.2
conv.i8
ret // return 2
}
}

.method public static void Execute()
{
.entrypoint
.locals init (class Invariant local0)
newobj instance void Invariant::.ctor()
stloc.0
ldloc.0
//Call int32::Foo()
callvirt instance int32 Invariant::Foo()
call void [mscorlib]System.Console::WriteLine(int32)
ldloc.0
// Call int64::Foo()
callvirt instance int64 Invariant::Foo()
call void [mscorlib]System.Console::WriteLine(int64)
ret
}
Willy.

"andrew lowe" <andrew dot lowe at geac dot com> wrote in message
news:uU**************@tk2msftngp13.phx.gbl...

<di********@discussion.microsoft.com> wrote in message
news:O0**************@TK2MSFTNGP09.phx.gbl...
> Hi,
>
> Why can I not overload on just the return type?

I believe Eiffel supports this



Nov 15 '05 #9

P: n/a
You already do have to SPECIFY RETURN TYPES.

"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:Oa**************@TK2MSFTNGP10.phx.gbl...

"Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
news:O6**************@TK2MSFTNGP11.phx.gbl...
It SHOULD be supported as its technically a DIFFERENT function signiture.
I think its stupid not to support this. Is there any valid reason why this is not implemented?

I cant think of one.


Its pretty simple, it heavily complicates the language for very little
benifit. I don't care to have to specify return type on every call, doubt
you would either. Even with defaults it is a messy situation.
Do you have a suggestion as to how to implement it without causing a major
complexity increase?
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message
news:ub**************@TK2MSFTNGP11.phx.gbl...
True, and ILASM also, here's a sample (compile with ilasm).

.assembly extern mscorlib
{
.publickeytoken = (B7 7A 5C 56 19 34 E0 89 )
.ver 1:0:5000:0
}

.assembly invaril
{
.hash algorithm 0x00008004
.ver 0:0:0:1
}

.class private Invariant
{
.method public specialname
instance void .ctor()
{
ret
}

.method public instance int32 Foo()
{
.locals init (int32 local0)
ldc.i4.1
ret //return 1
}

.method public instance int64 Foo()
{
.locals init (int64 local0)
ldc.i4.2
conv.i8
ret // return 2
}
}

.method public static void Execute()
{
.entrypoint
.locals init (class Invariant local0)
newobj instance void Invariant::.ctor()
stloc.0
ldloc.0
//Call int32::Foo()
callvirt instance int32 Invariant::Foo()
call void [mscorlib]System.Console::WriteLine(int32)
ldloc.0
// Call int64::Foo()
callvirt instance int64 Invariant::Foo()
call void [mscorlib]System.Console::WriteLine(int64)
ret
}
Willy.

"andrew lowe" <andrew dot lowe at geac dot com> wrote in message
news:uU**************@tk2msftngp13.phx.gbl...
>
> <di********@discussion.microsoft.com> wrote in message
> news:O0**************@TK2MSFTNGP09.phx.gbl...
> > Hi,
> >
> > Why can I not overload on just the return type?
>
> I believe Eiffel supports this
>
>



Nov 15 '05 #10

P: n/a
How does it heavily complicate a lanaguage that already supports
overloading.

Dont be stupid. Tard
"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:Oa**************@TK2MSFTNGP10.phx.gbl...

"Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
news:O6**************@TK2MSFTNGP11.phx.gbl...
It SHOULD be supported as its technically a DIFFERENT function signiture.
I think its stupid not to support this. Is there any valid reason why this is not implemented?

I cant think of one.


Its pretty simple, it heavily complicates the language for very little
benifit. I don't care to have to specify return type on every call, doubt
you would either. Even with defaults it is a messy situation.
Do you have a suggestion as to how to implement it without causing a major
complexity increase?
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message
news:ub**************@TK2MSFTNGP11.phx.gbl...
True, and ILASM also, here's a sample (compile with ilasm).

.assembly extern mscorlib
{
.publickeytoken = (B7 7A 5C 56 19 34 E0 89 )
.ver 1:0:5000:0
}

.assembly invaril
{
.hash algorithm 0x00008004
.ver 0:0:0:1
}

.class private Invariant
{
.method public specialname
instance void .ctor()
{
ret
}

.method public instance int32 Foo()
{
.locals init (int32 local0)
ldc.i4.1
ret //return 1
}

.method public instance int64 Foo()
{
.locals init (int64 local0)
ldc.i4.2
conv.i8
ret // return 2
}
}

.method public static void Execute()
{
.entrypoint
.locals init (class Invariant local0)
newobj instance void Invariant::.ctor()
stloc.0
ldloc.0
//Call int32::Foo()
callvirt instance int32 Invariant::Foo()
call void [mscorlib]System.Console::WriteLine(int32)
ldloc.0
// Call int64::Foo()
callvirt instance int64 Invariant::Foo()
call void [mscorlib]System.Console::WriteLine(int64)
ret
}
Willy.

"andrew lowe" <andrew dot lowe at geac dot com> wrote in message
news:uU**************@tk2msftngp13.phx.gbl...
>
> <di********@discussion.microsoft.com> wrote in message
> news:O0**************@TK2MSFTNGP09.phx.gbl...
> > Hi,
> >
> > Why can I not overload on just the return type?
>
> I believe Eiffel supports this
>
>



Nov 15 '05 #11

P: n/a
I would like to know how this tard codes C# WITHOUT specifying return types
ROFL

Genius!!
"Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
news:ee**************@TK2MSFTNGP10.phx.gbl...
You already do have to SPECIFY RETURN TYPES.

"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:Oa**************@TK2MSFTNGP10.phx.gbl...

"Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
news:O6**************@TK2MSFTNGP11.phx.gbl...
It SHOULD be supported as its technically a DIFFERENT function signiture.
I think its stupid not to support this. Is there any valid reason why this is not implemented?

I cant think of one.


Its pretty simple, it heavily complicates the language for very little
benifit. I don't care to have to specify return type on every call, doubt you would either. Even with defaults it is a messy situation.
Do you have a suggestion as to how to implement it without causing a major complexity increase?
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message
news:ub**************@TK2MSFTNGP11.phx.gbl...
> True, and ILASM also, here's a sample (compile with ilasm).
>
> .assembly extern mscorlib
> {
> .publickeytoken = (B7 7A 5C 56 19 34 E0 89 )
> .ver 1:0:5000:0
> }
>
> .assembly invaril
> {
> .hash algorithm 0x00008004
> .ver 0:0:0:1
> }
>
> .class private Invariant
> {
> .method public specialname
> instance void .ctor()
> {
> ret
> }
>
> .method public instance int32 Foo()
> {
> .locals init (int32 local0)
> ldc.i4.1
> ret //return 1
> }
>
> .method public instance int64 Foo()
> {
> .locals init (int64 local0)
> ldc.i4.2
> conv.i8
> ret // return 2
> }
> }
>
> .method public static void Execute()
> {
> .entrypoint
> .locals init (class Invariant local0)
> newobj instance void Invariant::.ctor()
> stloc.0
> ldloc.0
> //Call int32::Foo()
> callvirt instance int32 Invariant::Foo()
> call void [mscorlib]System.Console::WriteLine(int32)
> ldloc.0
> // Call int64::Foo()
> callvirt instance int64 Invariant::Foo()
> call void [mscorlib]System.Console::WriteLine(int64)
> ret
> }
>
>
> Willy.
>
> "andrew lowe" <andrew dot lowe at geac dot com> wrote in message
> news:uU**************@tk2msftngp13.phx.gbl...
> >
> > <di********@discussion.microsoft.com> wrote in message
> > news:O0**************@TK2MSFTNGP09.phx.gbl...
> > > Hi,
> > >
> > > Why can I not overload on just the return type?
> >
> > I believe Eiffel supports this
> >
> >
>
>



Nov 15 '05 #12

P: n/a
On Sat, 6 Dec 2003 17:51:15 +0100, "Alvin Bruney"
<alvin.bruney@.telia..com.> wrote:
It SHOULD be supported as its technically a DIFFERENT function signiture.

I think its stupid not to support this. Is there any valid reason why this
is not implemented?


First of because it isn't a different function signature. The return
type doesn't play a role in determining signature.

Secondly, as pointed out elsethread, in case you missed it, calling
a method without an assignment (using the method call in as an
expression in a Console.Writeln argument list is a good one) can't
tell the compiler which overload to invoke.

Oz
Nov 15 '05 #13

P: n/a
Well it IS logically a DIFFERENT signiture and it SHOULD therefore play a
ROLE in the method signiture.

An Int32 blahFn(Int32) is different from String blahFn(Int32)

Maybe not in todays implementation but it IS different and it SHOULD be
treated as such in the compiler.

There is no logical reason why this is a limitation on C#; just somebody
cant be arsed to have the return type as the signiture, ie., its a half
assed approach.
"ozbear" <oz*****@yahoo.com> wrote in message
news:3fd24bc8.220990640@news-server...
On Sat, 6 Dec 2003 17:51:15 +0100, "Alvin Bruney"
<alvin.bruney@.telia..com.> wrote:
It SHOULD be supported as its technically a DIFFERENT function signiture.

I think its stupid not to support this. Is there any valid reason why thisis not implemented?


First of because it isn't a different function signature. The return
type doesn't play a role in determining signature.

Secondly, as pointed out elsethread, in case you missed it, calling
a method without an assignment (using the method call in as an
expression in a Console.Writeln argument list is a good one) can't
tell the compiler which overload to invoke.

Oz

Nov 15 '05 #14

P: n/a
> First of because it isn't a different function signature. The return
type doesn't play a role in determining signature.
That's not entirely true. The framework *does differentiate signature by
return type. However, this feature is not implemented in C# or any other
..NET compatible language for that matter to date. But it is important to
note that the framework does support it and it can be implemented. Compiler
builders/vendors have the right to, and frequently exercise it, to choose
which features of the framework they intend to implement so long as it meets
the minimum requirements set forth by the standardization body (ECMA I
believe).

--
Regards,
Alvin Bruney
http://www.networkip.net/dotnet/tidbits/default.htm
"ozbear" <oz*****@yahoo.com> wrote in message
news:3fd24bc8.220990640@news-server... On Sat, 6 Dec 2003 17:51:15 +0100, "Alvin Bruney"
<alvin.bruney@.telia..com.> wrote:
It SHOULD be supported as its technically a DIFFERENT function signiture.

I think its stupid not to support this. Is there any valid reason why thisis not implemented?


First of because it isn't a different function signature. The return
type doesn't play a role in determining signature.

Secondly, as pointed out elsethread, in case you missed it, calling
a method without an assignment (using the method call in as an
expression in a Console.Writeln argument list is a good one) can't
tell the compiler which overload to invoke.

Oz

Nov 15 '05 #15

P: n/a

"Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
news:%2******************@TK2MSFTNGP11.phx.gbl...
I would like to know how this tard codes C# WITHOUT specifying return types ROFL

Genius!!

Take this class, with return type overloading.

public class Class
{
public string Method(){};
public StringBuilder Method(){};
public Control Method(){};
public Button Method(){};
}

now, on this set of calls, waht are your results?
string stringResult = Method(); //clear, string Method(){} should be called
StringBuilder stringBuilderResult = Method(); // clear, StringBuilder
Method(){} should be called
object objectResult = Method(); // ambigious, any method could be called.
Control controlResult = Method(); // ambigious, should Control Method() or
Button Method() be called?
Method(); //ambigious, any method cound be called;

Your only option would be to change code calling to something akin to(syntax
invented):

object objectResult = string:Method(); //0k
object objectResult = Button:Method(); //0k

As I said, by specifying the return type, in the call not the declaration.
Thats where the complication comes in, it adds extra call syntax. Not to say
I'd be totally adverse to return type overloading if a simple, easy to
follow syntax existed, but only if it didn't result in significant addition
of complexity. Return type overloading beats GetWorkingSet64 imho, but the
additional complexity of the feature may not make it worth it.

"Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
news:ee**************@TK2MSFTNGP10.phx.gbl...
You already do have to SPECIFY RETURN TYPES.

"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:Oa**************@TK2MSFTNGP10.phx.gbl...

"Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
news:O6**************@TK2MSFTNGP11.phx.gbl...
> It SHOULD be supported as its technically a DIFFERENT function

signiture.
>
> I think its stupid not to support this. Is there any valid reason why
this
> is not implemented?
>
> I cant think of one.
>

Its pretty simple, it heavily complicates the language for very little
benifit. I don't care to have to specify return type on every call, doubt you would either. Even with defaults it is a messy situation.
Do you have a suggestion as to how to implement it without causing a major complexity increase?

> "Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in

message > news:ub**************@TK2MSFTNGP11.phx.gbl...
> > True, and ILASM also, here's a sample (compile with ilasm).
> >
> > .assembly extern mscorlib
> > {
> > .publickeytoken = (B7 7A 5C 56 19 34 E0 89 )
> > .ver 1:0:5000:0
> > }
> >
> > .assembly invaril
> > {
> > .hash algorithm 0x00008004
> > .ver 0:0:0:1
> > }
> >
> > .class private Invariant
> > {
> > .method public specialname
> > instance void .ctor()
> > {
> > ret
> > }
> >
> > .method public instance int32 Foo()
> > {
> > .locals init (int32 local0)
> > ldc.i4.1
> > ret //return 1
> > }
> >
> > .method public instance int64 Foo()
> > {
> > .locals init (int64 local0)
> > ldc.i4.2
> > conv.i8
> > ret // return 2
> > }
> > }
> >
> > .method public static void Execute()
> > {
> > .entrypoint
> > .locals init (class Invariant local0)
> > newobj instance void Invariant::.ctor()
> > stloc.0
> > ldloc.0
> > //Call int32::Foo()
> > callvirt instance int32 Invariant::Foo()
> > call void [mscorlib]System.Console::WriteLine(int32)
> > ldloc.0
> > // Call int64::Foo()
> > callvirt instance int64 Invariant::Foo()
> > call void [mscorlib]System.Console::WriteLine(int64)
> > ret
> > }
> >
> >
> > Willy.
> >
> > "andrew lowe" <andrew dot lowe at geac dot com> wrote in message
> > news:uU**************@tk2msftngp13.phx.gbl...
> > >
> > > <di********@discussion.microsoft.com> wrote in message
> > > news:O0**************@TK2MSFTNGP09.phx.gbl...
> > > > Hi,
> > > >
> > > > Why can I not overload on just the return type?
> > >
> > > I believe Eiffel supports this
> > >
> > >
> >
> >
>
>



Nov 15 '05 #16

P: n/a
"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:#U**************@TK2MSFTNGP09.phx.gbl...

"Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
news:%2******************@TK2MSFTNGP11.phx.gbl...
I would like to know how this tard codes C# WITHOUT specifying return types
ROFL

Genius!!


Take this class, with return type overloading.

public class Class
{
public string Method(){};
public StringBuilder Method(){};
public Control Method(){};
public Button Method(){};
}

now, on this set of calls, waht are your results?
string stringResult = Method(); //clear, string Method(){} should be

called StringBuilder stringBuilderResult = Method(); // clear, StringBuilder
Method(){} should be called
object objectResult = Method(); // ambigious, any method could be called.
Call Object then have a specific object method its up to the caller to cast
to the appropriate type.
Control controlResult = Method(); // ambigious, should Control Method() or
Call Control method... Thats what he asked for if its a button, call the
Button one if thats the type tahts specified, no point in calling the Button
one if its a HScroll, no ambiguity
Button Method() be called?
Method(); //ambigious, any method cound be called;
Call the VOID method. No ambiguity.

Your only option would be to change code calling to something akin to(syntax invented):

object objectResult = string:Method(); //0k
object objectResult = Button:Method(); //0k

As I said, by specifying the return type, in the call not the declaration.
Thats where the complication comes in, it adds extra call syntax. Not to say I'd be totally adverse to return type overloading if a simple, easy to
follow syntax existed, but only if it didn't result in significant addition of complexity. Return type overloading beats GetWorkingSet64 imho, but the
additional complexity of the feature may not make it worth it.

"Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
news:ee**************@TK2MSFTNGP10.phx.gbl...
You already do have to SPECIFY RETURN TYPES.

"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:Oa**************@TK2MSFTNGP10.phx.gbl...
>
> "Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
> news:O6**************@TK2MSFTNGP11.phx.gbl...
> > It SHOULD be supported as its technically a DIFFERENT function
signiture.
> >
> > I think its stupid not to support this. Is there any valid reason why this
> > is not implemented?
> >
> > I cant think of one.
> >
>
> Its pretty simple, it heavily complicates the language for very little > benifit. I don't care to have to specify return type on every call,

doubt
> you would either. Even with defaults it is a messy situation.
> Do you have a suggestion as to how to implement it without causing a

major
> complexity increase?
>
> > "Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message > > news:ub**************@TK2MSFTNGP11.phx.gbl...
> > > True, and ILASM also, here's a sample (compile with ilasm).
> > >
> > > .assembly extern mscorlib
> > > {
> > > .publickeytoken = (B7 7A 5C 56 19 34 E0 89 )
> > > .ver 1:0:5000:0
> > > }
> > >
> > > .assembly invaril
> > > {
> > > .hash algorithm 0x00008004
> > > .ver 0:0:0:1
> > > }
> > >
> > > .class private Invariant
> > > {
> > > .method public specialname
> > > instance void .ctor()
> > > {
> > > ret
> > > }
> > >
> > > .method public instance int32 Foo()
> > > {
> > > .locals init (int32 local0)
> > > ldc.i4.1
> > > ret //return 1
> > > }
> > >
> > > .method public instance int64 Foo()
> > > {
> > > .locals init (int64 local0)
> > > ldc.i4.2
> > > conv.i8
> > > ret // return 2
> > > }
> > > }
> > >
> > > .method public static void Execute()
> > > {
> > > .entrypoint
> > > .locals init (class Invariant local0)
> > > newobj instance void Invariant::.ctor()
> > > stloc.0
> > > ldloc.0
> > > //Call int32::Foo()
> > > callvirt instance int32 Invariant::Foo()
> > > call void [mscorlib]System.Console::WriteLine(int32)
> > > ldloc.0
> > > // Call int64::Foo()
> > > callvirt instance int64 Invariant::Foo()
> > > call void [mscorlib]System.Console::WriteLine(int64)
> > > ret
> > > }
> > >
> > >
> > > Willy.
> > >
> > > "andrew lowe" <andrew dot lowe at geac dot com> wrote in message
> > > news:uU**************@tk2msftngp13.phx.gbl...
> > > >
> > > > <di********@discussion.microsoft.com> wrote in message
> > > > news:O0**************@TK2MSFTNGP09.phx.gbl...
> > > > > Hi,
> > > > >
> > > > > Why can I not overload on just the return type?
> > > >
> > > > I believe Eiffel supports this
> > > >
> > > >
> > >
> > >
> >
> >
>
>



Nov 15 '05 #17

P: n/a

"Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
news:OJ**************@tk2msftngp13.phx.gbl...
"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:#U**************@TK2MSFTNGP09.phx.gbl...

"Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
news:%2******************@TK2MSFTNGP11.phx.gbl...
I would like to know how this tard codes C# WITHOUT specifying return types
ROFL

Genius!!


Take this class, with return type overloading.

public class Class
{
public string Method(){};
public StringBuilder Method(){};
public Control Method(){};
public Button Method(){};
}

now, on this set of calls, waht are your results?
string stringResult = Method(); //clear, string Method(){} should be

called
StringBuilder stringBuilderResult = Method(); // clear, StringBuilder
Method(){} should be called
object objectResult = Method(); // ambigious, any method could be called.
Call Object then have a specific object method its up to the caller to cast to the appropriate type.
There is no method that returns object explicitly. The caller cannot cast to
an arbitrary type, the proper method has to be called, this begins to
introduce alot of guessing in.
Control controlResult = Method(); // ambigious, should Control Method()
or
Call Control method... Thats what he asked for if its a button, call the
Button one if thats the type tahts specified, no point in calling the Button one if its a HScroll, no ambiguity
Clear ambiguity, Button is a control, it can be assigned to either. If you
require the return type to match you lock in the methods pretty badly,
imagine the boost in casting...
Button Method() be called?
Method(); //ambigious, any method cound be called;


Call the VOID method. No ambiguity.


There is no void method. Some method has to be called

What about these two?
Method().Text = "Something"; //what gets called here?
Method().ToString(); //which method is called here?


Your only option would be to change code calling to something akin

to(syntax
invented):

object objectResult = string:Method(); //0k
object objectResult = Button:Method(); //0k

As I said, by specifying the return type, in the call not the declaration. Thats where the complication comes in, it adds extra call syntax. Not to

say
I'd be totally adverse to return type overloading if a simple, easy to
follow syntax existed, but only if it didn't result in significant

addition
of complexity. Return type overloading beats GetWorkingSet64 imho, but the additional complexity of the feature may not make it worth it.

Nov 15 '05 #18

P: n/a
Yes but when you code, you are specifying using Intellisense what overload
you want, why not use this information?

If he asked for Control Method give him that. if he wants button, give him
that.

Do what he asked

How hard is that?
"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:uz**************@TK2MSFTNGP10.phx.gbl...

"Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
news:OJ**************@tk2msftngp13.phx.gbl...
"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:#U**************@TK2MSFTNGP09.phx.gbl...

"Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
news:%2******************@TK2MSFTNGP11.phx.gbl...
> I would like to know how this tard codes C# WITHOUT specifying return types
> ROFL
>
> Genius!!
>

Take this class, with return type overloading.

public class Class
{
public string Method(){};
public StringBuilder Method(){};
public Control Method(){};
public Button Method(){};
}

now, on this set of calls, waht are your results?
string stringResult = Method(); //clear, string Method(){} should be called
StringBuilder stringBuilderResult = Method(); // clear, StringBuilder
Method(){} should be called
object objectResult = Method(); // ambigious, any method could be called.

Call Object then have a specific object method its up to the caller to

cast
to the appropriate type.


There is no method that returns object explicitly. The caller cannot cast

to an arbitrary type, the proper method has to be called, this begins to
introduce alot of guessing in.
Control controlResult = Method(); // ambigious, should Control
Method()
or

Call Control method... Thats what he asked for if its a button, call the
Button one if thats the type tahts specified, no point in calling the

Button
one if its a HScroll, no ambiguity


Clear ambiguity, Button is a control, it can be assigned to either. If you
require the return type to match you lock in the methods pretty badly,
imagine the boost in casting...
Button Method() be called?
Method(); //ambigious, any method cound be called;


Call the VOID method. No ambiguity.


There is no void method. Some method has to be called

What about these two?
Method().Text = "Something"; //what gets called here?
Method().ToString(); //which method is called here?
Your only option would be to change code calling to something akin

to(syntax
invented):

object objectResult = string:Method(); //0k
object objectResult = Button:Method(); //0k

As I said, by specifying the return type, in the call not the declaration. Thats where the complication comes in, it adds extra call syntax. Not
to say
I'd be totally adverse to return type overloading if a simple, easy to
follow syntax existed, but only if it didn't result in significant

addition
of complexity. Return type overloading beats GetWorkingSet64 imho, but

the additional complexity of the feature may not make it worth it.


Nov 15 '05 #19

P: n/a

"Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
news:OD**************@TK2MSFTNGP11.phx.gbl...
Yes but when you code, you are specifying using Intellisense what overload
you want, why not use this information?

If he asked for Control Method give him that. if he wants button, give him
that.

Do what he asked

How hard is that? Neither the compiler nor users not using the IDE have access to
intellisense. The compiler operates on files, period. Infact in large
projects the compiler isn't even usually invoked from VS during the final
build but instead some other build engine like nant. Some sort of language
syntax would have to exist to perform the call on the proper overload, like
I showed a post or two back. Any implicit defaults would have to be
overridable by language syntax or you severely limit and complicate method
calling(lose the ability to call non-void methods without taking a value,
for example, or to append methods calls on the end of method calls).

"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:uz**************@TK2MSFTNGP10.phx.gbl...

"Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
news:OJ**************@tk2msftngp13.phx.gbl...
"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:#U**************@TK2MSFTNGP09.phx.gbl...
>
> "Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
> news:%2******************@TK2MSFTNGP11.phx.gbl...
> > I would like to know how this tard codes C# WITHOUT specifying return > types
> > ROFL
> >
> > Genius!!
> >
>
> Take this class, with return type overloading.
>
> public class Class
> {
> public string Method(){};
> public StringBuilder Method(){};
> public Control Method(){};
> public Button Method(){};
> }
>
> now, on this set of calls, waht are your results?
> string stringResult = Method(); //clear, string Method(){} should be
called
> StringBuilder stringBuilderResult = Method(); // clear, StringBuilder > Method(){} should be called
> object objectResult = Method(); // ambigious, any method could be called.

Call Object then have a specific object method its up to the caller to

cast
to the appropriate type.


There is no method that returns object explicitly. The caller cannot cast to
an arbitrary type, the proper method has to be called, this begins to
introduce alot of guessing in.

> Control controlResult = Method(); // ambigious, should Control Method()
or

Call Control method... Thats what he asked for if its a button, call the Button one if thats the type tahts specified, no point in calling the Button
one if its a HScroll, no ambiguity


Clear ambiguity, Button is a control, it can be assigned to either. If

you require the return type to match you lock in the methods pretty badly,
imagine the boost in casting...

> Button Method() be called?
> Method(); //ambigious, any method cound be called;

Call the VOID method. No ambiguity.


There is no void method. Some method has to be called

What about these two?
Method().Text = "Something"; //what gets called here?
Method().ToString(); //which method is called here?

>
> Your only option would be to change code calling to something akin
to(syntax
> invented):
>
> object objectResult = string:Method(); //0k
> object objectResult = Button:Method(); //0k
>
> As I said, by specifying the return type, in the call not the

declaration.
> Thats where the complication comes in, it adds extra call syntax. Not to say
> I'd be totally adverse to return type overloading if a simple, easy
to > follow syntax existed, but only if it didn't result in significant
addition
> of complexity. Return type overloading beats GetWorkingSet64 imho,

but the
> additional complexity of the feature may not make it worth it.
>



Nov 15 '05 #20

P: n/a

"Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
news:OO**************@TK2MSFTNGP09.phx.gbl...
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.
Nov 15 '05 #21

P: n/a
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.

"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:uE**************@TK2MSFTNGP11.phx.gbl...

"Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
news:OD**************@TK2MSFTNGP11.phx.gbl...
Yes but when you code, you are specifying using Intellisense what overload
you want, why not use this information?

If he asked for Control Method give him that. if he wants button, give him that.

Do what he asked

How hard is that?

Neither the compiler nor users not using the IDE have access to
intellisense. The compiler operates on files, period. Infact in large
projects the compiler isn't even usually invoked from VS during the final
build but instead some other build engine like nant. Some sort of language
syntax would have to exist to perform the call on the proper overload,

like I showed a post or two back. Any implicit defaults would have to be
overridable by language syntax or you severely limit and complicate method
calling(lose the ability to call non-void methods without taking a value,
for example, or to append methods calls on the end of method calls).


"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:uz**************@TK2MSFTNGP10.phx.gbl...

"Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
news:OJ**************@tk2msftngp13.phx.gbl...
> "Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
> news:#U**************@TK2MSFTNGP09.phx.gbl...
> >
> > "Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
> > news:%2******************@TK2MSFTNGP11.phx.gbl...
> > > I would like to know how this tard codes C# WITHOUT specifying return
> > types
> > > ROFL
> > >
> > > Genius!!
> > >
> >
> > Take this class, with return type overloading.
> >
> > public class Class
> > {
> > public string Method(){};
> > public StringBuilder Method(){};
> > public Control Method(){};
> > public Button Method(){};
> > }
> >
> > now, on this set of calls, waht are your results?
> > string stringResult = Method(); //clear, string Method(){} should be > called
> > StringBuilder stringBuilderResult = Method(); // clear,

StringBuilder > > Method(){} should be called
> > object objectResult = Method(); // ambigious, any method could be
called.
>
> Call Object then have a specific object method its up to the caller to cast
> to the appropriate type.

There is no method that returns object explicitly. The caller cannot cast
to
an arbitrary type, the proper method has to be called, this begins to
introduce alot of guessing in.

>
> > Control controlResult = Method(); // ambigious, should Control

Method()
or
>
> Call Control method... Thats what he asked for if its a button, call

the > Button one if thats the type tahts specified, no point in calling the Button
> one if its a HScroll, no ambiguity

Clear ambiguity, Button is a control, it can be assigned to either. If you require the return type to match you lock in the methods pretty badly,
imagine the boost in casting...

>
> > Button Method() be called?
> > Method(); //ambigious, any method cound be called;
>
> Call the VOID method. No ambiguity.
>

There is no void method. Some method has to be called

What about these two?
Method().Text = "Something"; //what gets called here?
Method().ToString(); //which method is called here?
> >
> > Your only option would be to change code calling to something akin
> to(syntax
> > invented):
> >
> > object objectResult = string:Method(); //0k
> > object objectResult = Button:Method(); //0k
> >
> > As I said, by specifying the return type, in the call not the
declaration.
> > Thats where the complication comes in, it adds extra call syntax. Not
to
> say
> > I'd be totally adverse to return type overloading if a simple,

easy to > > follow syntax existed, but only if it didn't result in significant
> addition
> > of complexity. Return type overloading beats GetWorkingSet64 imho, but the
> > additional complexity of the feature may not make it worth it.
> >



Nov 15 '05 #22

P: n/a
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.

"Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
news:uX**************@TK2MSFTNGP11.phx.gbl...
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.

"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:uE**************@TK2MSFTNGP11.phx.gbl...

"Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
news:OD**************@TK2MSFTNGP11.phx.gbl...
Yes but when you code, you are specifying using Intellisense what overload you want, why not use this information?

If he asked for Control Method give him that. if he wants button, give him that.

Do what he asked

How hard is that?

Neither the compiler nor users not using the IDE have access to
intellisense. The compiler operates on files, period. Infact in large
projects the compiler isn't even usually invoked from VS during the final
build but instead some other build engine like nant. Some sort of language syntax would have to exist to perform the call on the proper overload,

like
I showed a post or two back. Any implicit defaults would have to be
overridable by language syntax or you severely limit and complicate method calling(lose the ability to call non-void methods without taking a value, for example, or to append methods calls on the end of method calls).


"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:uz**************@TK2MSFTNGP10.phx.gbl...
>
> "Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
> news:OJ**************@tk2msftngp13.phx.gbl...
> > "Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message > > news:#U**************@TK2MSFTNGP09.phx.gbl...
> > >
> > > "Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
> > > news:%2******************@TK2MSFTNGP11.phx.gbl...
> > > > I would like to know how this tard codes C# WITHOUT specifying
return
> > > types
> > > > ROFL
> > > >
> > > > Genius!!
> > > >
> > >
> > > Take this class, with return type overloading.
> > >
> > > public class Class
> > > {
> > > public string Method(){};
> > > public StringBuilder Method(){};
> > > public Control Method(){};
> > > public Button Method(){};
> > > }
> > >
> > > now, on this set of calls, waht are your results?
> > > string stringResult = Method(); //clear, string Method(){} should be > > called
> > > StringBuilder stringBuilderResult = Method(); // clear, StringBuilder
> > > Method(){} should be called
> > > object objectResult = Method(); // ambigious, any method could
be > called.
> >
> > Call Object then have a specific object method its up to the caller to > cast
> > to the appropriate type.
>
> There is no method that returns object explicitly. The caller cannot

cast
to
> an arbitrary type, the proper method has to be called, this begins
to > introduce alot of guessing in.
>
> >
> > > Control controlResult = Method(); // ambigious, should Control
Method()
> or
> >
> > Call Control method... Thats what he asked for if its a button, call
the
> > Button one if thats the type tahts specified, no point in calling the > Button
> > one if its a HScroll, no ambiguity
>
> Clear ambiguity, Button is a control, it can be assigned to either.

If you
> require the return type to match you lock in the methods pretty
badly, > imagine the boost in casting...
>
> >
> > > Button Method() be called?
> > > Method(); //ambigious, any method cound be called;
> >
> > Call the VOID method. No ambiguity.
> >
>
> There is no void method. Some method has to be called
>
> What about these two?
> Method().Text = "Something"; //what gets called here?
> Method().ToString(); //which method is called here?
>
>
> > >
> > > Your only option would be to change code calling to something akin > > to(syntax
> > > invented):
> > >
> > > object objectResult = string:Method(); //0k
> > > object objectResult = Button:Method(); //0k
> > >
> > > As I said, by specifying the return type, in the call not the
> declaration.
> > > Thats where the complication comes in, it adds extra call syntax. Not
to
> > say
> > > I'd be totally adverse to return type overloading if a simple, easy
to
> > > follow syntax existed, but only if it didn't result in

significant > > addition
> > > of complexity. Return type overloading beats GetWorkingSet64

imho, but
> the
> > > additional complexity of the feature may not make it worth it.
> > >
>
>



Nov 15 '05 #23

P: n/a

"Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
news:eE**************@TK2MSFTNGP11.phx.gbl...
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.

"Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
news:uX**************@TK2MSFTNGP11.phx.gbl...
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.

"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:uE**************@TK2MSFTNGP11.phx.gbl...

"Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
news:OD**************@TK2MSFTNGP11.phx.gbl...
> Yes but when you code, you are specifying using Intellisense what overload
> you want, why not use this information?
>
> If he asked for Control Method give him that. if he wants button, give
him
> that.
>
> Do what he asked
>
> How hard is that?
Neither the compiler nor users not using the IDE have access to
intellisense. The compiler operates on files, period. Infact in large
projects the compiler isn't even usually invoked from VS during the final build but instead some other build engine like nant. Some sort of language syntax would have to exist to perform the call on the proper overload,

like
I showed a post or two back. Any implicit defaults would have to be
overridable by language syntax or you severely limit and complicate method calling(lose the ability to call non-void methods without taking a value, for example, or to append methods calls on the end of method calls).
>
>
> "Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
> news:uz**************@TK2MSFTNGP10.phx.gbl...
> >
> > "Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
> > news:OJ**************@tk2msftngp13.phx.gbl...
> > > "Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message > > > news:#U**************@TK2MSFTNGP09.phx.gbl...
> > > >
> > > > "Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
> > > > news:%2******************@TK2MSFTNGP11.phx.gbl...
> > > > > I would like to know how this tard codes C# WITHOUT
specifying > return
> > > > types
> > > > > ROFL
> > > > >
> > > > > Genius!!
> > > > >
> > > >
> > > > Take this class, with return type overloading.
> > > >
> > > > public class Class
> > > > {
> > > > public string Method(){};
> > > > public StringBuilder Method(){};
> > > > public Control Method(){};
> > > > public Button Method(){};
> > > > }
> > > >
> > > > now, on this set of calls, waht are your results?
> > > > string stringResult = Method(); //clear, string Method(){} should
be
> > > called
> > > > StringBuilder stringBuilderResult = Method(); // clear,
StringBuilder
> > > > Method(){} should be called
> > > > object objectResult = Method(); // ambigious, any method could

be > > called.
> > >
> > > Call Object then have a specific object method its up to the caller
to
> > cast
> > > to the appropriate type.
> >
> > There is no method that returns object explicitly. The caller cannot cast
> to
> > an arbitrary type, the proper method has to be called, this begins

to > > introduce alot of guessing in.
> >
> > >
> > > > Control controlResult = Method(); // ambigious, should Control
> Method()
> > or
> > >
> > > Call Control method... Thats what he asked for if its a button, call the
> > > Button one if thats the type tahts specified, no point in
calling the
> > Button
> > > one if its a HScroll, no ambiguity
> >
> > Clear ambiguity, Button is a control, it can be assigned to

either. If you
> > require the return type to match you lock in the methods pretty badly, > > imagine the boost in casting...
> >
> > >
> > > > Button Method() be called?
> > > > Method(); //ambigious, any method cound be called;
> > >
> > > Call the VOID method. No ambiguity.
> > >
> >
> > There is no void method. Some method has to be called
> >
> > What about these two?
> > Method().Text = "Something"; //what gets called here?
> > Method().ToString(); //which method is called here?
> >
> >
> > > >
> > > > Your only option would be to change code calling to something akin > > > to(syntax
> > > > invented):
> > > >
> > > > object objectResult = string:Method(); //0k
> > > > object objectResult = Button:Method(); //0k
> > > >
> > > > As I said, by specifying the return type, in the call not the
> > declaration.
> > > > Thats where the complication comes in, it adds extra call syntax. Not
> to
> > > say
> > > > I'd be totally adverse to return type overloading if a simple,

easy
to
> > > > follow syntax existed, but only if it didn't result in significant > > > addition
> > > > of complexity. Return type overloading beats GetWorkingSet64 imho, but
> > the
> > > > additional complexity of the feature may not make it worth it.
> > > >
> >
> >
>
>



Nov 15 '05 #24

P: n/a

"Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
news:uX**************@TK2MSFTNGP11.phx.gbl...
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.
"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:uE**************@TK2MSFTNGP11.phx.gbl...

"Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
news:OD**************@TK2MSFTNGP11.phx.gbl...
Yes but when you code, you are specifying using Intellisense what overload you want, why not use this information?

If he asked for Control Method give him that. if he wants button, give him that.

Do what he asked

How hard is that?

Neither the compiler nor users not using the IDE have access to
intellisense. The compiler operates on files, period. Infact in large
projects the compiler isn't even usually invoked from VS during the final
build but instead some other build engine like nant. Some sort of language syntax would have to exist to perform the call on the proper overload,

like
I showed a post or two back. Any implicit defaults would have to be
overridable by language syntax or you severely limit and complicate method calling(lose the ability to call non-void methods without taking a value, for example, or to append methods calls on the end of method calls).


"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:uz**************@TK2MSFTNGP10.phx.gbl...
>
> "Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
> news:OJ**************@tk2msftngp13.phx.gbl...
> > "Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message > > news:#U**************@TK2MSFTNGP09.phx.gbl...
> > >
> > > "Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
> > > news:%2******************@TK2MSFTNGP11.phx.gbl...
> > > > I would like to know how this tard codes C# WITHOUT specifying
return
> > > types
> > > > ROFL
> > > >
> > > > Genius!!
> > > >
> > >
> > > Take this class, with return type overloading.
> > >
> > > public class Class
> > > {
> > > public string Method(){};
> > > public StringBuilder Method(){};
> > > public Control Method(){};
> > > public Button Method(){};
> > > }
> > >
> > > now, on this set of calls, waht are your results?
> > > string stringResult = Method(); //clear, string Method(){} should be > > called
> > > StringBuilder stringBuilderResult = Method(); // clear, StringBuilder
> > > Method(){} should be called
> > > object objectResult = Method(); // ambigious, any method could
be > called.
> >
> > Call Object then have a specific object method its up to the caller to > cast
> > to the appropriate type.
>
> There is no method that returns object explicitly. The caller cannot

cast
to
> an arbitrary type, the proper method has to be called, this begins
to > introduce alot of guessing in.
>
> >
> > > Control controlResult = Method(); // ambigious, should Control
Method()
> or
> >
> > Call Control method... Thats what he asked for if its a button, call
the
> > Button one if thats the type tahts specified, no point in calling the > Button
> > one if its a HScroll, no ambiguity
>
> Clear ambiguity, Button is a control, it can be assigned to either.

If you
> require the return type to match you lock in the methods pretty
badly, > imagine the boost in casting...
>
> >
> > > Button Method() be called?
> > > Method(); //ambigious, any method cound be called;
> >
> > Call the VOID method. No ambiguity.
> >
>
> There is no void method. Some method has to be called
>
> What about these two?
> Method().Text = "Something"; //what gets called here?
> Method().ToString(); //which method is called here?
>
>
> > >
> > > Your only option would be to change code calling to something akin > > to(syntax
> > > invented):
> > >
> > > object objectResult = string:Method(); //0k
> > > object objectResult = Button:Method(); //0k
> > >
> > > As I said, by specifying the return type, in the call not the
> declaration.
> > > Thats where the complication comes in, it adds extra call syntax. Not
to
> > say
> > > I'd be totally adverse to return type overloading if a simple, easy
to
> > > follow syntax existed, but only if it didn't result in

significant > > addition
> > > of complexity. Return type overloading beats GetWorkingSet64

imho, but
> the
> > > additional complexity of the feature may not make it worth it.
> > >
>
>



Nov 15 '05 #25

P: n/a
What if we limit this to value types and not reference types?

No inheritence worries.
"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:#d**************@tk2msftngp13.phx.gbl...

"Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
news:uX**************@TK2MSFTNGP11.phx.gbl...
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.

"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:uE**************@TK2MSFTNGP11.phx.gbl...

"Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
news:OD**************@TK2MSFTNGP11.phx.gbl...
> Yes but when you code, you are specifying using Intellisense what overload
> you want, why not use this information?
>
> If he asked for Control Method give him that. if he wants button, give
him
> that.
>
> Do what he asked
>
> How hard is that?
Neither the compiler nor users not using the IDE have access to
intellisense. The compiler operates on files, period. Infact in large
projects the compiler isn't even usually invoked from VS during the final build but instead some other build engine like nant. Some sort of language syntax would have to exist to perform the call on the proper overload,

like
I showed a post or two back. Any implicit defaults would have to be
overridable by language syntax or you severely limit and complicate method calling(lose the ability to call non-void methods without taking a value, for example, or to append methods calls on the end of method calls).
>
>
> "Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
> news:uz**************@TK2MSFTNGP10.phx.gbl...
> >
> > "Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
> > news:OJ**************@tk2msftngp13.phx.gbl...
> > > "Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message > > > news:#U**************@TK2MSFTNGP09.phx.gbl...
> > > >
> > > > "Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
> > > > news:%2******************@TK2MSFTNGP11.phx.gbl...
> > > > > I would like to know how this tard codes C# WITHOUT
specifying > return
> > > > types
> > > > > ROFL
> > > > >
> > > > > Genius!!
> > > > >
> > > >
> > > > Take this class, with return type overloading.
> > > >
> > > > public class Class
> > > > {
> > > > public string Method(){};
> > > > public StringBuilder Method(){};
> > > > public Control Method(){};
> > > > public Button Method(){};
> > > > }
> > > >
> > > > now, on this set of calls, waht are your results?
> > > > string stringResult = Method(); //clear, string Method(){} should
be
> > > called
> > > > StringBuilder stringBuilderResult = Method(); // clear,
StringBuilder
> > > > Method(){} should be called
> > > > object objectResult = Method(); // ambigious, any method could

be > > called.
> > >
> > > Call Object then have a specific object method its up to the caller
to
> > cast
> > > to the appropriate type.
> >
> > There is no method that returns object explicitly. The caller cannot cast
> to
> > an arbitrary type, the proper method has to be called, this begins

to > > introduce alot of guessing in.
> >
> > >
> > > > Control controlResult = Method(); // ambigious, should Control
> Method()
> > or
> > >
> > > Call Control method... Thats what he asked for if its a button, call the
> > > Button one if thats the type tahts specified, no point in
calling the
> > Button
> > > one if its a HScroll, no ambiguity
> >
> > Clear ambiguity, Button is a control, it can be assigned to

either. If you
> > require the return type to match you lock in the methods pretty badly, > > imagine the boost in casting...
> >
> > >
> > > > Button Method() be called?
> > > > Method(); //ambigious, any method cound be called;
> > >
> > > Call the VOID method. No ambiguity.
> > >
> >
> > There is no void method. Some method has to be called
> >
> > What about these two?
> > Method().Text = "Something"; //what gets called here?
> > Method().ToString(); //which method is called here?
> >
> >
> > > >
> > > > Your only option would be to change code calling to something akin > > > to(syntax
> > > > invented):
> > > >
> > > > object objectResult = string:Method(); //0k
> > > > object objectResult = Button:Method(); //0k
> > > >
> > > > As I said, by specifying the return type, in the call not the
> > declaration.
> > > > Thats where the complication comes in, it adds extra call syntax. Not
> to
> > > say
> > > > I'd be totally adverse to return type overloading if a simple,

easy
to
> > > > follow syntax existed, but only if it didn't result in significant > > > addition
> > > > of complexity. Return type overloading beats GetWorkingSet64 imho, but
> > the
> > > > additional complexity of the feature may not make it worth it.
> > > >
> >
> >
>
>



Nov 15 '05 #26

P: n/a

<di********@discussion.microsoft.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
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" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:#d**************@tk2msftngp13.phx.gbl...

"Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
news:uX**************@TK2MSFTNGP11.phx.gbl...
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.

"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:uE**************@TK2MSFTNGP11.phx.gbl...
>
> "Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
> news:OD**************@TK2MSFTNGP11.phx.gbl...
> > Yes but when you code, you are specifying using Intellisense what
overload
> > you want, why not use this information?
> >
>
>
> > If he asked for Control Method give him that. if he wants button, give him
> > that.
> >
> > Do what he asked
> >
> > How hard is that?
> Neither the compiler nor users not using the IDE have access to
> intellisense. The compiler operates on files, period. Infact in large > projects the compiler isn't even usually invoked from VS during the

final
> build but instead some other build engine like nant. Some sort of

language
> syntax would have to exist to perform the call on the proper overload, like
> I showed a post or two back. Any implicit defaults would have to be
> overridable by language syntax or you severely limit and complicate

method
> calling(lose the ability to call non-void methods without taking a

value,
> for example, or to append methods calls on the end of method calls).
> >
> >
> > "Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message > > news:uz**************@TK2MSFTNGP10.phx.gbl...
> > >
> > > "Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
> > > news:OJ**************@tk2msftngp13.phx.gbl...
> > > > "Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in

message
> > > > news:#U**************@TK2MSFTNGP09.phx.gbl...
> > > > >
> > > > > "Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
> > > > > news:%2******************@TK2MSFTNGP11.phx.gbl...
> > > > > > I would like to know how this tard codes C# WITHOUT specifying > > return
> > > > > types
> > > > > > ROFL
> > > > > >
> > > > > > Genius!!
> > > > > >
> > > > >
> > > > > Take this class, with return type overloading.
> > > > >
> > > > > public class Class
> > > > > {
> > > > > public string Method(){};
> > > > > public StringBuilder Method(){};
> > > > > public Control Method(){};
> > > > > public Button Method(){};
> > > > > }
> > > > >
> > > > > now, on this set of calls, waht are your results?
> > > > > string stringResult = Method(); //clear, string Method(){}

should
be
> > > > called
> > > > > StringBuilder stringBuilderResult = Method(); // clear,
> StringBuilder
> > > > > Method(){} should be called
> > > > > object objectResult = Method(); // ambigious, any method could be
> > > called.
> > > >
> > > > Call Object then have a specific object method its up to the

caller
to
> > > cast
> > > > to the appropriate type.
> > >
> > > There is no method that returns object explicitly. The caller cannot > cast
> > to
> > > an arbitrary type, the proper method has to be called, this
begins
to
> > > introduce alot of guessing in.
> > >
> > > >
> > > > > Control controlResult = Method(); // ambigious, should
Control > > Method()
> > > or
> > > >
> > > > Call Control method... Thats what he asked for if its a button, call
> the
> > > > Button one if thats the type tahts specified, no point in calling the
> > > Button
> > > > one if its a HScroll, no ambiguity
> > >
> > > Clear ambiguity, Button is a control, it can be assigned to

either.
If
> you
> > > require the return type to match you lock in the methods pretty

badly,
> > > imagine the boost in casting...
> > >
> > > >
> > > > > Button Method() be called?
> > > > > Method(); //ambigious, any method cound be called;
> > > >
> > > > Call the VOID method. No ambiguity.
> > > >
> > >
> > > There is no void method. Some method has to be called
> > >
> > > What about these two?
> > > Method().Text = "Something"; //what gets called here?
> > > Method().ToString(); //which method is called here?
> > >
> > >
> > > > >
> > > > > Your only option would be to change code calling to

something akin
> > > > to(syntax
> > > > > invented):
> > > > >
> > > > > object objectResult = string:Method(); //0k
> > > > > object objectResult = Button:Method(); //0k
> > > > >
> > > > > As I said, by specifying the return type, in the call not

the > > > declaration.
> > > > > Thats where the complication comes in, it adds extra call

syntax.
> Not
> > to
> > > > say
> > > > > I'd be totally adverse to return type overloading if a simple, easy
> to
> > > > > follow syntax existed, but only if it didn't result in

significant
> > > > addition
> > > > > of complexity. Return type overloading beats GetWorkingSet64

imho,
> but
> > > the
> > > > > additional complexity of the feature may not make it worth it. > > > > >
> > >
> > >
> >
> >
>
>



Nov 15 '05 #27

P: n/a

"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:Oc**************@tk2msftngp13.phx.gbl...

<di********@discussion.microsoft.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
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. And, might I add, not support what the runtime is capable of supporting,
AFAIK anway.


"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:#d**************@tk2msftngp13.phx.gbl...

"Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
news:uX**************@TK2MSFTNGP11.phx.gbl...
> 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.
>
>
>
> "Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
> news:uE**************@TK2MSFTNGP11.phx.gbl...
> >
> > "Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
> > news:OD**************@TK2MSFTNGP11.phx.gbl...
> > > Yes but when you code, you are specifying using Intellisense what > overload
> > > you want, why not use this information?
> > >
> >
> >
> > > If he asked for Control Method give him that. if he wants button, give
> him
> > > that.
> > >
> > > Do what he asked
> > >
> > > How hard is that?
> > Neither the compiler nor users not using the IDE have access to
> > intellisense. The compiler operates on files, period. Infact in large > > projects the compiler isn't even usually invoked from VS during
the final
> > build but instead some other build engine like nant. Some sort of
language
> > syntax would have to exist to perform the call on the proper

overload, > like
> > I showed a post or two back. Any implicit defaults would have to be > > overridable by language syntax or you severely limit and complicate method
> > calling(lose the ability to call non-void methods without taking a
value,
> > for example, or to append methods calls on the end of method calls). > > >
> > >
> > > "Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message > > > news:uz**************@TK2MSFTNGP10.phx.gbl...
> > > >
> > > > "Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
> > > > news:OJ**************@tk2msftngp13.phx.gbl...
> > > > > "Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in
message
> > > > > news:#U**************@TK2MSFTNGP09.phx.gbl...
> > > > > >
> > > > > > "Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message > > > > > > news:%2******************@TK2MSFTNGP11.phx.gbl...
> > > > > > > I would like to know how this tard codes C# WITHOUT

specifying
> > > return
> > > > > > types
> > > > > > > ROFL
> > > > > > >
> > > > > > > Genius!!
> > > > > > >
> > > > > >
> > > > > > Take this class, with return type overloading.
> > > > > >
> > > > > > public class Class
> > > > > > {
> > > > > > public string Method(){};
> > > > > > public StringBuilder Method(){};
> > > > > > public Control Method(){};
> > > > > > public Button Method(){};
> > > > > > }
> > > > > >
> > > > > > now, on this set of calls, waht are your results?
> > > > > > string stringResult = Method(); //clear, string Method(){}
should
> be
> > > > > called
> > > > > > StringBuilder stringBuilderResult = Method(); // clear,
> > StringBuilder
> > > > > > Method(){} should be called
> > > > > > object objectResult = Method(); // ambigious, any method could be
> > > > called.
> > > > >
> > > > > Call Object then have a specific object method its up to the
caller
> to
> > > > cast
> > > > > to the appropriate type.
> > > >
> > > > There is no method that returns object explicitly. The caller

cannot
> > cast
> > > to
> > > > an arbitrary type, the proper method has to be called, this begins to
> > > > introduce alot of guessing in.
> > > >
> > > > >
> > > > > > Control controlResult = Method(); // ambigious, should Control > > > Method()
> > > > or
> > > > >
> > > > > Call Control method... Thats what he asked for if its a button, call
> > the
> > > > > Button one if thats the type tahts specified, no point in

calling
> the
> > > > Button
> > > > > one if its a HScroll, no ambiguity
> > > >
> > > > Clear ambiguity, Button is a control, it can be assigned to

either.
If
> > you
> > > > require the return type to match you lock in the methods pretty badly,
> > > > imagine the boost in casting...
> > > >
> > > > >
> > > > > > Button Method() be called?
> > > > > > Method(); //ambigious, any method cound be called;
> > > > >
> > > > > Call the VOID method. No ambiguity.
> > > > >
> > > >
> > > > There is no void method. Some method has to be called
> > > >
> > > > What about these two?
> > > > Method().Text = "Something"; //what gets called here?
> > > > Method().ToString(); //which method is called here?
> > > >
> > > >
> > > > > >
> > > > > > Your only option would be to change code calling to something akin
> > > > > to(syntax
> > > > > > invented):
> > > > > >
> > > > > > object objectResult = string:Method(); //0k
> > > > > > object objectResult = Button:Method(); //0k
> > > > > >
> > > > > > As I said, by specifying the return type, in the call not the > > > > declaration.
> > > > > > Thats where the complication comes in, it adds extra call
syntax.
> > Not
> > > to
> > > > > say
> > > > > > I'd be totally adverse to return type overloading if a simple, > easy
> > to
> > > > > > follow syntax existed, but only if it didn't result in
significant
> > > > > addition
> > > > > > of complexity. Return type overloading beats GetWorkingSet64 imho,
> > but
> > > > the
> > > > > > additional complexity of the feature may not make it worth it. > > > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>



Nov 15 '05 #28

P: n/a
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

"Alvin Bruney" <alvin.bruney@.telia..com.> wrote in message
news:uQ**************@TK2MSFTNGP09.phx.gbl...
Well it IS logically a DIFFERENT signiture and it SHOULD therefore play a
ROLE in the method signiture.

An Int32 blahFn(Int32) is different from String blahFn(Int32)

Maybe not in todays implementation but it IS different and it SHOULD be
treated as such in the compiler.

There is no logical reason why this is a limitation on C#; just somebody
cant be arsed to have the return type as the signiture, ie., its a half
assed approach.
"ozbear" <oz*****@yahoo.com> wrote in message
news:3fd24bc8.220990640@news-server...
On Sat, 6 Dec 2003 17:51:15 +0100, "Alvin Bruney"
<alvin.bruney@.telia..com.> wrote:
It SHOULD be supported as its technically a DIFFERENT function signiture.
I think its stupid not to support this. Is there any valid reason why thisis not implemented?


First of because it isn't a different function signature. The return
type doesn't play a role in determining signature.

Secondly, as pointed out elsethread, in case you missed it, calling
a method without an assignment (using the method call in as an
expression in a Console.Writeln argument list is a good one) can't
tell the compiler which overload to invoke.

Oz


Nov 15 '05 #29

P: n/a
Krishnan <kr*********************@myrealbox.com> wrote:
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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #30

P: n/a
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]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Krishnan <kr*********************@myrealbox.com> wrote:
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.

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

Nov 15 '05 #31

P: n/a
Krishnan <kr*********************@myrealbox.com> wrote:
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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #32

This discussion thread is closed

Replies have been disabled for this discussion.