VB.NET Overloading problem/question

[Brian Haynes]

I am having a problem with overloading. An example:

Public Class Base
...
End Class

Public Class Derived Inherits Base
...
End Class

Public Class Client
Public Sub MethodX()
Dim obj as Base = new Derived()
MethodY(obj)
End Sub

Public Sub MethodY(arg as Base)
...
End Sub

Public Sub MethodY(arg as Derived)
...
End Sub
End Class

MethodX calls the MethodY that has a Base as a parameter, even though obj is
really a Derived object. The MethodY that has a Derived as a parameter would
seem to be a closer match to me. In my actual situation, I am getting the
Derived object elsewhere and do not know what type it is other than it is a
subclass of Base, so I cannot cast it more specifically. I am essentially
trying to do a select...case on the real object type polymorphically . Any
suggestions?

Thanks,
Brian Haynes

[Chad Z. Hower aka Kudzu]

=?Utf-8?B?QnJpYW4gSGF 5bmVz?= <Br*********@di scussions.micro soft.com>
wrote in news:36******** *************** ***********@mic rosoft.com:

Public Sub MethodY(arg as Base)
...
End Sub

Public Sub MethodY(arg as Derived)
...
End Sub
End Class

MethodX calls the MethodY that has a Base as a parameter, even though
obj is really a Derived object. The MethodY that has a Derived as a

This is normal. Overloads are resolved at build time based on the type of the reference, not the
type of the instance. To resolve at run time would be very slow.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programmin g is an art form that fights back"

Make your ASP.NET applications run faster
http://www.atozed.com/IntraWeb/

[Jay B. Harlow [MVP - Outlook]]

Brian,
In addition to the other comments.

Consider moving MethodY directly or indirectly into Base as overridable
(directly).

Something like:

| Public Class Base
| ...

Public Overridable Sub MethodY()
' do work for Base's Method Y here.
End Sub

| End Class
|
| Public Class Derived Inherits Base
| ...

Public Overrides Sub MethodY()
' do work for Derived's Method Y here.
End Sub

| End Class
|
| Public Class Client
| Public Sub MethodX()
| Dim obj as Base = new Derived()
obj.MethodY()
| End Sub
|
| End Class

You may need to pass Client as a parameter above if MethodY needs behavior
from Client...
If MethodY "needs" to be in Client, then consider a double dispatch
(indirectly).

| Public Class Base
| ...

Public Overridable Sub MethodY(theClie nt As Client)
theClient.Metho dY(Me)
End Sub

| End Class
|
| Public Class Derived Inherits Base
| ...

Public Overrides Sub MethodY(theClie nt As Client)
theClient.Metho dY(Me)
End Sub

| End Class
|
| Public Class Client
| Public Sub MethodX()
| Dim obj as Base = new Derived()
obj.MethodY(Me)
| End Sub
|
| Public Sub MethodY(arg as Base)

' do work for Base's Method Y here.
| End Sub
|
| Public Sub MethodY(arg as Derived)

' do work for Derived's Method Y here.
| End Sub
| End Class

Using either method may introduce coupling between the classes that is not
desirable, in which case I would consider introducing an Interface that Base
or Client implements to help decouple the classes...

Hope this helps
Jay

"Brian Haynes" <Br*********@di scussions.micro soft.com> wrote in message
news:36******** *************** ***********@mic rosoft.com...
|I am having a problem with overloading. An example:
|
| Public Class Base
| ...
| End Class
|
| Public Class Derived Inherits Base
| ...
| End Class
|
| Public Class Client
| Public Sub MethodX()
| Dim obj as Base = new Derived()
| MethodY(obj)
| End Sub
|
| Public Sub MethodY(arg as Base)
| ...
| End Sub
|
| Public Sub MethodY(arg as Derived)
| ...
| End Sub
| End Class
|
| MethodX calls the MethodY that has a Base as a parameter, even though obj
is
| really a Derived object. The MethodY that has a Derived as a parameter
would
| seem to be a closer match to me. In my actual situation, I am getting the
| Derived object elsewhere and do not know what type it is other than it is
a
| subclass of Base, so I cannot cast it more specifically. I am essentially
| trying to do a select...case on the real object type polymorphically . Any
| suggestions?
|
| Thanks,
| Brian Haynes

[Brian Haynes]

"Chad Z. Hower aka Kudzu" wrote:

This is normal. Overloads are resolved at build time based on the type of the reference, not the
type of the instance. To resolve at run time would be very slow.

Example:

Dim i as Object = new Integer
Debug.WriteLine (i.ToString())

The output is 0, not "System.Object" . Obviously the ToString call is being
resolved based on the type of the object, not the reference. Isn't it a
little inconsistent for overloads to be resolved on reference type and
overrides to be resolved on object type?

[Brian Haynes]

"Jay B. Harlow [MVP - Outlook]" wrote:

Brian,
In addition to the other comments.

Consider moving MethodY directly or indirectly into Base as overridable
(directly). If MethodY "needs" to be in Client, then consider a double dispatch
(indirectly).

Unfortunately, doing either would be much worse than what I am trying to
avoid. My actual situation is a little more complicated than my example. It
looks like the simplest solution to my problem is going to be doing something
like this:

If typeof obj is Derived Then
MethodY(CType(o bj, Derived))
ElseIf typeof obj is Derived2 Then
MethodY(CType(o bj, Derived2))
....
Else
MethodY(CType(o bj, Base))
End If

Thanks for the suggestions though.
-Brian

[Chad Z. Hower aka Kudzu]

=?Utf-8?B?QnJpYW4gSGF 5bmVz?= <Br*********@di scussions.micro soft.com>
wrote in news:68******** *************** ***********@mic rosoft.com:

Dim i as Object = new Integer
Debug.WriteLine (i.ToString())

The output is 0, not "System.Object" . Obviously the ToString call is
being resolved based on the type of the object, not the reference.
Isn't it a little inconsistent for overloads to be resolved on
reference type and overrides to be resolved on object type?

Because ToString is overridden, which is different than overloading. You are comparing two totally
different concepts.

Overloading compares parameters.

Overriding is on actaul methods of the class.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programmin g is an art form that fights back"

Develop ASP.NET applications easier and in less time:
http://www.atozed.com/IntraWeb/

[Brian Haynes]

"Chad Z. Hower aka Kudzu" wrote:

Because ToString is overridden, which is different than overloading. You are comparing two totally
different concepts.

Overloading compares parameters.

Overriding is on actaul methods of the class.

Yes, I realize that. But isn't the override resolution done at run time in
that case? If we have time to resolve the overrides at run time, why can't
we spare time for the overloads? It only really becomes an issue when the
overloads contain types that are related in an ancestor-descendant
relationship by inheritance/implementation. The cases where the overloads
are not related this way could be safely done at runtime.
-Brian

[Chad Z. Hower aka Kudzu]

=?Utf-8?B?QnJpYW4gSGF 5bmVz?= <Br*********@di scussions.micro soft.com>
wrote in news:44******** *************** ***********@mic rosoft.com:

Overloading compares parameters.

Overriding is on actaul methods of the class.
Yes, I realize that. But isn't the override resolution done at run
time in that case? If we have time to resolve the overrides at run

No, overloads are NEVER done at run time. Overrides are.

Overloads - always at build time.
Overrides - always at compile time.
time, why can't we spare time for the overloads? It only really
Because it would not only be slower, it would require a lot more memory to track it, a VMT of sorts
and it also isnt wanted. The overloads are compile time and thats what its designed for.
becomes an issue when the overloads contain types that are related in
an ancestor-descendant relationship by inheritance/implementation.
The cases where the overloads are not related this way could be safely
done at runtime.

It wouldnt be proper though. Its not a short coming or for performance reasons, its by design.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programmin g is an art form that fights back"

Make your ASP.NET applications run faster
http://www.atozed.com/IntraWeb/

[Larry Lard]

Brian Haynes wrote:

"Jay B. Harlow [MVP - Outlook]" wrote:

Brian,
In addition to the other comments.

Consider moving MethodY directly or indirectly into Base as overridable
(directly).

If MethodY "needs" to be in Client, then consider a double dispatch
(indirectly).

Unfortunately, doing either would be much worse than what I am trying to
avoid. My actual situation is a little more complicated than my example. It
looks like the simplest solution to my problem is going to be doing something
like this:

If typeof obj is Derived Then
MethodY(CType(o bj, Derived))
ElseIf typeof obj is Derived2 Then
MethodY(CType(o bj, Derived2))
...
Else
MethodY(CType(o bj, Base))
End If

Thanks for the suggestions though.
-Brian

If that is what you want then that is what overriding is for! Define
MethodY in Base, define Overrides MethodY in each Derivedn, then just

MethodY(obj)

will call the appropriate one...

--
Larry Lard
Replies to group please

[Phill. W]

"Brian Haynes" <Br*********@di scussions.micro soft.com> wrote in message
news:36******** *************** ***********@mic rosoft.com...
.. . .

I am getting the Derived object elsewhere and do not know what type
it is other than it is a subclass of Base, so I cannot cast it more
specifically.

Yes, you can, so long as you first ask it what type it actually is!
This might get you a bit closer to where you want to be ...

Dim obj as Base = GetPossiblyDeri vedObject()

If TypeOf obj Is Derived Then
MethodY( DirectCast( obj, Derived ) )
Else
MethodY( obj )
End If

HTH,
Phill W.