Overloading or not?

[Claus Konrad]

Hi

Just curious on why the C# language does not regard the "return object" as
part of the method signature? Is there any reasonable explaination on why
the following is not allowed?

public DataView GetContacts(string company)
{
....stuff
}

public DataTable GetContacts(string company)
{
...other stuff
}

/Claus

 

[Jon Skeet [C# MVP]]

Just curious on why the C# language does not regard the "return object" as
part of the method signature? Is there any reasonable explaination on why
the following is not allowed?

public DataView GetContacts(string company)
{
...stuff
}

public DataTable GetContacts(string company)
{
..other stuff
}

Absolutely - it would make code very hard to understand, and in many
cases there'd be ambiguity. For instance:

object o = GetContacts("foo");
or even just
GetContacts("foo");

or

DoSomething(GetContacts("foo"))

where there are overloads for DoSomething() which accept a DataView or
a DataTable.

Yes, you could cast to get the right overload - but it would be a bit
bizarre, IMO.

To me, it doesn't make much sense for what you end up doing with the
return value (if anything) to affect what method is called. It's
information which only becomes relevant *after* the method is called in
every other way. (Compare this with parameters, which are relevant
*before* the method is called.)

 

[Brad Williams]

There are multiple reasons, but one is that explicit disambiguation would
often be required. Eg, consider if the caller of GetContacts was sticking
the result into an element of an array. The compiler would have to give an
error, at least until you explicitly cast the return before assigning it to
the array element. Once you have to make such casts, you've more than lost
any gain in whatever "elegance" you were hoping for.

Brad Williams