Why Overloads needed

[Lee Silver]

In a base class I have the following 2 declarations:

Overridable Sub Remove(ByVal wIndex As Integer)
and

Overridable Sub Remove(ByVal wValue As Object)

In an immediately derived class I have the following declaration:

Overloads Overrides Sub Remove(ByVal wIndex As Integer)

Why is Overloads needed in the derived class? Without it intellisense tells me
"Remove shadows an overloadable method in the base class. If you want to
overload the base method this method must be declared Overloads?" Since the
signatures of the 2 methods are the same, I would think the compiler could
determine that the derived method is overriding the Remove(Integer) vs
Remove(Object). What am I missing?

Is it accurate to deduce, based on the intellisense message, that if Remove
weren't overloaded in the base cass I wouldn't need Overloads in the derived one?

--
// Lee Silver
// Information Concepts Inc.
// http://www.information-concepts.com

Facilitating the automated conversion of Data into Information
since 1982

[Cor Ligthert]

Hi Lee,

Probably you are right, however VB.net is full of this kind of things which
seems to be adepted from C.

Another thing in this is that you have to cast a lot of things which can
only be casted one way because the accepting value/object only accept that
object/value.

However promished is in the next version a kind of spellchecker, which
corrects that.

(It is not completly dumb, it checks of course if you are not by accident
using an existing method which is by some methods very clear however with
others very unclear).

An example from what I find dump

dim A as integer = CInt(2/2)

Cor

[Herfried K. Wagner [MVP]]

* Lee Silver <LS*****@information-concepts.com> scripsit:

In a base class I have the following 2 declarations:

Overridable Sub Remove(ByVal wIndex As Integer)
and

Overridable Sub Remove(ByVal wValue As Object)

In an immediately derived class I have the following declaration:

Overloads Overrides Sub Remove(ByVal wIndex As Integer)

Why is Overloads needed in the derived class? Without it intellisense
tells me "Remove shadows an overloadable method in the base class. If
you want to overload the base method this method must be declared
Overloads?" Since the signatures of the 2 methods are the same, I
would think the compiler could determine that the derived method is
overriding the Remove(Integer) vs Remove(Object). What am I missing?

It's not for the compiler, it's for the person who reads the code. More
info can be found by setting the caret onto 'Overloads' and pressing the
F1 key.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[Lee Silver]

Herfried:

It's not for the compiler, it's for the person who reads the code. More
info can be found by setting the caret onto 'Overloads' and pressing the
F1 key.

I had previously F1'd on Overloads, and the explanation didn't help me :). I
would think that the Overrides' would tell the reader of the code that there is
an identically named/signed function in the parent class.

Quoting from the 'about Overloads keyword': "The Overloads keyword declares a
property or method with the same name as an existing member, but with an
argument list different from the original member." I don't think this applies
because the methods have the same argument list (unless the compiler somehow
can't tell which method is being overridden).

Therefore I'm thinking this paragraph applies: "Overloads can also be used to
shadow an existing member, or set of overloaded members, in a base class. When
you use Overloads in this way, you declare the property or method with the same
name and the same argument list as the base class member, and you do not supply
the Shadows keyword."

It would seem from this that I don't need Overridable in the base class and
Overrides in the derived class -- just Shadows in the derived class. Then why
have Overridable and Overrides if I also need Overloads? I'm missing something,
but I don't know what; because to me, Overriding isn't the same as Shadowing
(the former has identical arguments and the latter doesn't).
--
// Lee Silver
// Information Concepts Inc.
// http://www.information-concepts.com

Facilitating the automated conversion of Data into Information
since 1982

[Jay B. Harlow [MVP - Outlook]]

Lee,
In addition to the other comments:

Overloads is needed so the compiler will know if Sub Remove(Object) will be
available via your derived class!

Consider the following:

Option Strict On

Public Class Base

Public Overridable Sub Remove(ByVal wIndex As Integer)

End Sub

Public Overridable Sub Remove(ByVal wValue As Object)

End Sub

Public Sub Main()
Dim overlord As New OverloadedBase
overlord.Remove(10)
overlord.Remove("Jay")

Dim underlord As New ShadowsBase
underlord.Remove(10)
underlord.Remove("Jay")
End Sub

End Class

Public Class OverloadedBase
Inherits Base

Public Overloads Overrides Sub Remove(ByVal wIndex As Integer)
End Sub

End Class
Public Class ShadowsBase
Inherits Base

Public Overrides Sub Remove(ByVal wIndex As Integer)
End Sub

End Class
The underload.Remove("Jay") method has an error, because you forgot to
include Overloads, so Shadows was implicitly used. Shadows causes
Base.Remove(Object) to be hidden in OverloadedBase set of methods. Without
the Option Strict On, VB.NET will attempt to convert "jay" to an integer at
run time on the underload.Remove("Jay") line.

Shadows is used for versioning, so methods added to version 2 of classes
don't suddenly cause surprises in classes that were designed for version 1
of the base class.

NOTE: Shadows base can be written as:

Public Class ShadowsBase
Inherits Base

Public Shadows Overrides Sub Remove(ByVal wIndex As Integer)
End Sub

End Class

Which will remove the warning about adding either Shadows or Overloads.

Hope this helps
Jay

"Lee Silver" <LS*****@information-concepts.com> wrote in message
news:7f***************************@msgid.meganewss ervers.com...

In a base class I have the following 2 declarations:

Overridable Sub Remove(ByVal wIndex As Integer)
and

Overridable Sub Remove(ByVal wValue As Object)

In an immediately derived class I have the following declaration:

Overloads Overrides Sub Remove(ByVal wIndex As Integer)

Why is Overloads needed in the derived class? Without it intellisense tells me "Remove shadows an overloadable method in the base class. If you want to
overload the base method this method must be declared Overloads?" Since the signatures of the 2 methods are the same, I would think the compiler could
determine that the derived method is overriding the Remove(Integer) vs
Remove(Object). What am I missing?

Is it accurate to deduce, based on the intellisense message, that if Remove weren't overloaded in the base cass I wouldn't need Overloads in the derived one?
--
// Lee Silver
// Information Concepts Inc.
// http://www.information-concepts.com

Facilitating the automated conversion of Data into Information
since 1982

[Herfried K. Wagner [MVP]]

* Lee Silver <LS*****@information-concepts.com> scripsit:
[...]

Have a look at Jay's explanation... I should really take more sleep.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[Herfried K. Wagner [MVP]]

Addendum:

MSDN says:

<msdn>
Overloads can also be used to shadow an existing member, or set of
overloaded members, in a base class. When you use Overloads in this way,
you declare the property or method with the same name and the same
argument list as the base class member, and you do not supply the
Shadows keyword.
</msdn>

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[Jay B. Harlow [MVP - Outlook]]

Doh!
Ignore this part, it causes a compile error:

NOTE: Shadows base can be written as:

Public Class ShadowsBase
Inherits Base

Public Shadows Overrides Sub Remove(ByVal wIndex As Integer)
End Sub

End Class

Which will remove the warning about adding either Shadows or Overloads. However what I show in the above is effectively what is happening when you
don't use Overloads.

Hope this helps
Jay

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:O8**************@TK2MSFTNGP11.phx.gbl... Lee,
In addition to the other comments:

Overloads is needed so the compiler will know if Sub Remove(Object) will be available via your derived class!

Consider the following:

Option Strict On

Public Class Base

Public Overridable Sub Remove(ByVal wIndex As Integer)

End Sub

Public Overridable Sub Remove(ByVal wValue As Object)

End Sub

Public Sub Main()
Dim overlord As New OverloadedBase
overlord.Remove(10)
overlord.Remove("Jay")

Dim underlord As New ShadowsBase
underlord.Remove(10)
underlord.Remove("Jay")
End Sub

End Class

Public Class OverloadedBase
Inherits Base

Public Overloads Overrides Sub Remove(ByVal wIndex As Integer)
End Sub

End Class
Public Class ShadowsBase
Inherits Base

Public Overrides Sub Remove(ByVal wIndex As Integer)
End Sub

End Class
The underload.Remove("Jay") method has an error, because you forgot to
include Overloads, so Shadows was implicitly used. Shadows causes
Base.Remove(Object) to be hidden in OverloadedBase set of methods. Without
the Option Strict On, VB.NET will attempt to convert "jay" to an integer at run time on the underload.Remove("Jay") line.

Shadows is used for versioning, so methods added to version 2 of classes
don't suddenly cause surprises in classes that were designed for version 1
of the base class.

NOTE: Shadows base can be written as:

Public Class ShadowsBase
Inherits Base

Public Shadows Overrides Sub Remove(ByVal wIndex As Integer)
End Sub

End Class

Which will remove the warning about adding either Shadows or Overloads.

Hope this helps
Jay

"Lee Silver" <LS*****@information-concepts.com> wrote in message
news:7f***************************@msgid.meganewss ervers.com...

In a base class I have the following 2 declarations:

Overridable Sub Remove(ByVal wIndex As Integer)
and

Overridable Sub Remove(ByVal wValue As Object)

In an immediately derived class I have the following declaration:

Overloads Overrides Sub Remove(ByVal wIndex As Integer)

Why is Overloads needed in the derived class? Without it intellisense

tells me

"Remove shadows an overloadable method in the base class. If you want to
overload the base method this method must be declared Overloads?" Since

the

signatures of the 2 methods are the same, I would think the compiler could determine that the derived method is overriding the Remove(Integer) vs
Remove(Object). What am I missing?

Is it accurate to deduce, based on the intellisense message, that if

Remove

weren't overloaded in the base cass I wouldn't need Overloads in the

derived one?

--
// Lee Silver
// Information Concepts Inc.
// http://www.information-concepts.com

Facilitating the automated conversion of Data into Information
since 1982

[Lee Silver]

Jay:

Aha, I think I got it -- the key phrase is "Shadows is used for versioning".
Without Overloads, Shadows would be required; and since neither is implied I
need to specify Overloads.

But this brings up something interesting... In my Base class I have a
non-overloaded overridable property, Item. In my derived class I declare it
Overrides, without Overloads or Shadows, and it compiles just fine. If at some
point in the future I modify Base class to overload Item, won't that break my
derived class?

--
// Lee Silver
// Information Concepts Inc.
// http://www.information-concepts.com

Facilitating the automated conversion of Data into Information
since 1982

Lee,
In addition to the other comments:

Overloads is needed so the compiler will know if Sub Remove(Object) will be
available via your derived class!

Consider the following:

Option Strict On

Public Class Base

Public Overridable Sub Remove(ByVal wIndex As Integer)

End Sub

Public Overridable Sub Remove(ByVal wValue As Object)

End Sub

Public Sub Main()
Dim overlord As New OverloadedBase
overlord.Remove(10)
overlord.Remove("Jay")

Dim underlord As New ShadowsBase
underlord.Remove(10)
underlord.Remove("Jay")
End Sub

End Class

Public Class OverloadedBase
Inherits Base

Public Overloads Overrides Sub Remove(ByVal wIndex As Integer)
End Sub

End Class
Public Class ShadowsBase
Inherits Base

Public Overrides Sub Remove(ByVal wIndex As Integer)
End Sub

End Class
The underload.Remove("Jay") method has an error, because you forgot to
include Overloads, so Shadows was implicitly used. Shadows causes
Base.Remove(Object) to be hidden in OverloadedBase set of methods. Without
the Option Strict On, VB.NET will attempt to convert "jay" to an integer at
run time on the underload.Remove("Jay") line.

Shadows is used for versioning, so methods added to version 2 of classes
don't suddenly cause surprises in classes that were designed for version 1
of the base class.

NOTE: Shadows base can be written as:

Public Class ShadowsBase
Inherits Base

Public Shadows Overrides Sub Remove(ByVal wIndex As Integer)
End Sub

End Class

Which will remove the warning about adding either Shadows or Overloads.

Hope this helps
Jay

[Jay B. Harlow [MVP - Outlook]]

Lee,
You example is largely the reason VB.NET defaults to Shadows.

Your derived class currently does not have an overloaded Item property, if
you add an overloaded Item property to the base. Your derived class still
will not have an overloaded Item property!

You will need to visit your derived class and decide if you want the
overloaded Item in your derived class also...

Hope this helps
Jay

"Lee Silver" <LS*****@information-concepts.com> wrote in message
news:33**************************@msgid.meganewsse rvers.com...

Jay:

Aha, I think I got it -- the key phrase is "Shadows is used for versioning". Without Overloads, Shadows would be required; and since neither is implied I need to specify Overloads.

But this brings up something interesting... In my Base class I have a
non-overloaded overridable property, Item. In my derived class I declare it Overrides, without Overloads or Shadows, and it compiles just fine. If at some point in the future I modify Base class to overload Item, won't that break my derived class?

--
// Lee Silver
// Information Concepts Inc.
// http://www.information-concepts.com

Facilitating the automated conversion of Data into Information
since 1982

Lee,
In addition to the other comments:

Overloads is needed so the compiler will know if Sub Remove(Object) will be available via your derived class!

Consider the following:

Option Strict On

Public Class Base

Public Overridable Sub Remove(ByVal wIndex As Integer)

End Sub

Public Overridable Sub Remove(ByVal wValue As Object)

End Sub

Public Sub Main()
Dim overlord As New OverloadedBase
overlord.Remove(10)
overlord.Remove("Jay")

Dim underlord As New ShadowsBase
underlord.Remove(10)
underlord.Remove("Jay")
End Sub

End Class

Public Class OverloadedBase
Inherits Base

Public Overloads Overrides Sub Remove(ByVal wIndex As Integer)
End Sub

End Class
Public Class ShadowsBase
Inherits Base

Public Overrides Sub Remove(ByVal wIndex As Integer)
End Sub

End Class
The underload.Remove("Jay") method has an error, because you forgot to
include Overloads, so Shadows was implicitly used. Shadows causes
Base.Remove(Object) to be hidden in OverloadedBase set of methods. Without the Option Strict On, VB.NET will attempt to convert "jay" to an integer at run time on the underload.Remove("Jay") line.

Shadows is used for versioning, so methods added to version 2 of classes
don't suddenly cause surprises in classes that were designed for version 1 of the base class.

NOTE: Shadows base can be written as:

Public Class ShadowsBase
Inherits Base

Public Shadows Overrides Sub Remove(ByVal wIndex As Integer)
End Sub

End Class

Which will remove the warning about adding either Shadows or Overloads.

Hope this helps
Jay

[Lee Silver]

Jay:

Your derived class currently does not have an overloaded Item property, if
you add an overloaded Item property to the base. Your derived class still
will not have an overloaded Item property!

I don't mind adding the Overloads keyword; and I don't want to beat this to
death or be dense -- but I do want to understand...

My base and derived classes each have a single Item property; so it's not
overloaded in either. You state that if I add an overloaded Item to my base I
still won't have one in my derived class. I agree; but I don't see how that's
different than the way my Remove methods are currently declared -- the base
class has an overloaded method and the derived class overrides only one of them.

Well, I just tried overloading the Item property in my base class and the Item
declaration in my derived class got flagged as needing Overloads. I then tried
overriding both properties in the derived class and both declaration got
flagged. So it seems that when a method/property is (implicitly) overloaded in
the base class it must be explicitly overloaded in the derived class. I guess I
don't see why the Overrides keyword isn't sufficient.

--
// Lee Silver
// Information Concepts Inc.
// http://www.information-concepts.com

Facilitating the automated conversion of Data into Information
since 1982

[Jay B. Harlow [MVP - Outlook]]

Lee,

My base and derived classes each have a single Item property; so it's not
overloaded in either. You state that if I add an overloaded Item to my base I still won't have one in my derived class. I agree; but I don't see how that's different than the way my Remove methods are currently declared -- Its a versioning thing. ;-) Mostly when you are deriving from class library
classes.

Java for example does it the other way. In Java when you add an overload in
the base any derived classes automatically gain the overload, this has known
to cause problems occasional. The .NET designers decided rather then allow
these potential problems to Shadow by default rather then overload by
default. Of course this may cause other problems, its a tradeoff either
way...

Also you are assuming that the derived class is going to be compiled, what
happens when derived class is already compiled? I can compile an assembly
under version 1.0 of a class library, and run it under version 2.0 of a
class library without recompiling my original assembly...

NOTE: Think of your MainForm class overriding a method in Microsoft's Form
class. When you upgrade to .NET 2.0 if Microsoft added an overload to that
method in the Form class, this may cause problems in your derived class. To
minimize these problems, the default is to Shadow, hence the warning.
different than the way my Remove methods are currently declared -- the base class has an overloaded method and the derived class overrides only one of them.
That's the point! your derived class overrides only one of them. You only
get one of them in the derived class unless you add Overloads!

Again refer to my overload example, when you use intellisense on the
underlord variable, how many Remove methods are listed? How many are listed
for the overlord variable?

Hope this helps
Jay

"Lee Silver" <LS*****@information-concepts.com> wrote in message
news:aa**************************@msgid.meganewsse rvers.com... Jay:

Your derived class currently does not have an overloaded Item property, if you add an overloaded Item property to the base. Your derived class still will not have an overloaded Item property!

I don't mind adding the Overloads keyword; and I don't want to beat this

to death or be dense -- but I do want to understand...

My base and derived classes each have a single Item property; so it's not
overloaded in either. You state that if I add an overloaded Item to my base I still won't have one in my derived class. I agree; but I don't see how that's different than the way my Remove methods are currently declared -- the base class has an overloaded method and the derived class overrides only one of them.
Well, I just tried overloading the Item property in my base class and the Item declaration in my derived class got flagged as needing Overloads. I then tried overriding both properties in the derived class and both declaration got
flagged. So it seems that when a method/property is (implicitly) overloaded in the base class it must be explicitly overloaded in the derived class. I guess I don't see why the Overrides keyword isn't sufficient.

--
// Lee Silver
// Information Concepts Inc.
// http://www.information-concepts.com

Facilitating the automated conversion of Data into Information
since 1982

[Lee Silver]

Jay:

I think I got it now. Thanks for your patience in explaining it.
--
// Lee Silver
// Information Concepts Inc.
// http://www.information-concepts.com

Facilitating the automated conversion of Data into Information
since 1982

Java for example does it the other way. In Java when you add an overload in
the base any derived classes automatically gain the overload, this has known
to cause problems occasional. The .NET designers decided rather then allow
these potential problems to Shadow by default rather then overload by
default. Of course this may cause other problems, its a tradeoff either
way...

Also you are assuming that the derived class is going to be compiled, what
happens when derived class is already compiled? I can compile an assembly
under version 1.0 of a class library, and run it under version 2.0 of a
class library without recompiling my original assembly...

NOTE: Think of your MainForm class overriding a method in Microsoft's Form
class. When you upgrade to .NET 2.0 if Microsoft added an overload to that
method in the Form class, this may cause problems in your derived class. To
minimize these problems, the default is to Shadow, hence the warning.