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#?
31  2228 
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#?
<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
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#?
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#?
<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
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
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
"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
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
>
>
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
>
>
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
> >
> >
>
>
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
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
> 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
"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
> > >
> > >
> >
> >
>
>
"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
> > > >
> > > >
> > >
> > >
> >
> >
>
>
"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.
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.
"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.
>
"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.
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.
> >
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.
> > >
>
>
"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.
> > > >
> >
> >
>
>
"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.
> > >
>
>
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.
> > > >
> >
> >
>
>
<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. > > > > >
> > >
> > >
> >
> >
>
>
"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. > > > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
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
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
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
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Terje Slettebų |
last post by:
To round off my trilogy of "why"'s about PHP... :) If this subject have been
discussed before, I'd appreciate a pointer to it. I again haven't found it
in a search of the PHP groups.
The PHP...
|
by: Dave Theese |
last post by:
Hello all,
I'm trying to get a grasp of the difference between specializing a function
template and overloading it. The example below has a primary template, a
specialization and an overload. ...
|
by: |
last post by:
Hi all,
I've been using C++ for quite a while now and I've come to the point where I need to overload new
and delete inorder to track memory and probably some profiling stuff too. I know that...
|
by: zeus |
last post by:
I know function overloading is not supported in C.
I have a few questions about this:
1. Why? is it from technical reasons? if so, which?
2. why wasn't it introduced to the ANSI?
3. Is there any...
|
by: JaSeong Ju |
last post by:
I would like to overload a C function. Is there any easy way to do this?
|
by: brzozo2 |
last post by:
Hello, this program might look abit long, but it's pretty simple and
easy to follow. What it does is read from a file, outputs the contents
to screen, and then writes them to a different file. It...
|
by: lordkain |
last post by:
is it possible to do some kind of function overloading in c? and that
the return type is different
|
by: placid |
last post by:
Hi all,
Is it possible to be able to do the following in Python?
class Test:
def __init__(self):
pass
def puts(self, str):
print str
|
by: Matthew |
last post by:
Am I correct in thinking there is no method/function overloading of any
kind in any version of PHP?
Thanks,
Matthew
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
