method overloading and references

[Daniel Gustafsson]

Hi there, hmm, I've just started with C# and I'm experimenting with method
overloading.
It seems like it's not possible to override method using return types, only
parameters. Is that by design, anyway around that or something? I.e. I'd
like to have the same method return either a DataReader or a DataAdapter
depending on the lvalue when calling it.

And another question. If I have my method returning a value, can it return
it by reference or does it always, always copy the object?

Anyhow, it all boils down to the fact that my class will have methods that
are supposed to retrieve database results for me, and I want them to be able
to provide me both with DataAdapters (for easy integration with components)
and DataReaders (in the case I want to use the result in a loop instead of a
component). I want to do this as seemless and simple as possible without
having any duplication of code, 3x as many methods or stuff like that AND
the fact that it has to be optimal performance-wize.

 

[Jon Skeet]

Hi there, hmm, I've just started with C# and I'm experimenting with method
overloading.
It seems like it's not possible to override method using return types, only
parameters. Is that by design, anyway around that or something?

It's by design - how would you be able to distinguish them at the
client side? For instance:

MyMethod();

could return a value, but I don't *have* to use it - which version
would that call?

I.e. I'd
like to have the same method return either a DataReader or a DataAdapter
depending on the lvalue when calling it.

That strikes me as a fairly confusing interface, to be honest.

And another question. If I have my method returning a value, can it return
it by reference or does it always, always copy the object?

It doesn't "return it by reference" - it returns *a* reference. You
need to understand exactly what the difference between reference types
and value types are.

If you want to make a copy of the object, you should probably do that
in the method, and return a reference to the copy.

Anyhow, it all boils down to the fact that my class will have methods that
are supposed to retrieve database results for me, and I want them to be able
to provide me both with DataAdapters (for easy integration with components)
and DataReaders (in the case I want to use the result in a loop instead of a
component). I want to do this as seemless and simple as possible without
having any duplication of code, 3x as many methods or stuff like that AND
the fact that it has to be optimal performance-wize.

Well, you could provide another parameter to say what type of reference
to return, and declare it as returning "object", leaving it to the
caller to cast it. That doesn't seem as nice a way as having a strongly
typed return value though. I'd suggest either having different API
classes, or *possibly* (and I don't like this particularly either) have
two interfaces, one of which describes returning a DataReader and one
of which describes returning a DataAdapter. Then use explicit interface
implementation to tell the difference between the two, and let the
client cast their initial reference to one of the two interfaces
depending on what they want to do.

 

[Christian]

It seems like it's not possible to override method using return types,
only
Override methods must have same signature, that means even return type
Did you intend overload?

I.e. I'd like to have the same method return either a DataReader or a DataAdapter
depending on the lvalue when calling it.

lvalue?? Left Value?
public Class A
{
public DataReader YourMethod()
{
...
}
public DataAdatpter YourMethod()
{
...
}
}
DataReader dr = YourMethod( ); // This way???
Left Value is optional so how can we distinguish 2 methods?

And another question. If I have my method returning a value, can it return
it by reference or does it always, always copy the object?

if return type is a reference type it is implicit a reference, not a copy

 

[Daniel Gustafsson]

DataReader dr = YourMethod( ); // This way???
Left Value is optional so how can we distinguish 2 methods?

Yeah, I figured that was the case why it didn't work.

if return type is a reference type it is implicit a reference, not a copy

So I don't have to worry about returning DataAdapters/DataReaders will give
me a performance hit compared to having an out-parameter?

 

[Christian]

So I don't have to worry about returning DataAdapters/DataReaders will give
me a performance hit compared to having an out-parameter?

No, returning a reference type shoul mean return 4 bytes indicating where
the object is located in the HEAP

 

[Daniel Gustafsson]

No, returning a reference type shoul mean return 4 bytes indicating where
the object is located in the HEAP

Ok, but afaik structures are value types, there is no way to return a
reference rather than getting it copied? the "ref" keyword only works for
parameters afaik. in c++ I can easily , and transparently, have my
functions return a reference to a value type.

 

[Christian]

As struct are value types if you want a method return a reference to it you
should box it in an object,
but which are the reason for doing such an odd thing?

 

[Daniel Gustafsson]

As struct are value types if you want a method return a reference to it you
should box it in an object,
but which are the reason for doing such an odd thing?

Well, I didn't mean DataAdapters earlier on but I meant DataSets (for
components) and I've explained why I wanted to be able to fetch both types
as simplistic as possible.

And the returning structs -question was just out of curiousity since I did
some experimentation and it didn't seem like I could return references the
way I can in c++. I'm trying to figure all this out in a really short
timespan.

 

[Stu Smith]

Actually I believe the framework does allow method overloading based on
return type, it's just that none of the current .NET languages support that.

I'm willing to be told I'm wrong though....

 

[Jon Skeet]

Actually I believe the framework does allow method overloading based on
return type, it's just that none of the current .NET languages support that.

I'm willing to be told I'm wrong though....

Nope, you're right, which is a bit of a surprise to me.

I've just managed to edit some IL which demonstrates it working.

Personally I hope it never *is* supported by any .NET languages though
- it's really nasty, IMO