VB.Net Polymorphic Bug!

[Bob]

Hi,
'Shadowed' properties are not polymorphic. (See thread 'Inheritance and late
binding')
They should be.
Problem:
Base class has read only property 'X'.
Derived class must have read / write property 'X'.
Can't override Base class 'X' because of different structure.
So you Shadow the base class 'X' in the derived class.
Pass an instance of the derived class to a function.
Read 'X' in the function. You get the base class read not the derived
class.
Workaround is to relax the interface of the Base class 'X' so that it is
read/write and use Overrides instead of Shadows.
Fixed in next build perhaps?
Bob

 

[Jay B. Harlow [MVP - Outlook]]

Bob,
The entire point of "Shadows" is that they are not polymorphic!

You should only use Shadows for version control! For example you release
version one MainForm that has a Widget method on it. Microsoft releases .NET
2.0 what includes Form.Widget. Seeing as Form.Widget may be incompatible
with MainForm.Widget the default is to Shadow which means that
MainForm.Widget does not override Form.Widget. If the default was overrides
(polymorphism) you would possibly be causing some unpleasant & unexpected,
not to mention very difficult to track down bugs.

What I do when I need to shadow a property, such as when I need to add an
Attribute to the property for the designer. I implement it in terms of the
base property. Which in your sample will not work.

Hope this helps
Jay

 

[Scott Swigart]

Shadows isn't supposed to be polymorphic. Overridable/Overrides is meant to
be polymorphic. The real problem is that you can't specify different
accessors on the read/write properties. Meaning, it might be nice to have a
public read, and a private write. I believe this will change in Whidbey (VS
2005).

 

[Bob]

Hi,
After my initial annoyance with Shadows I can see a need for Shadows to be
not Polymorphic. My need would be solved but it would leave another logical
hole by precluding accessing the base class behaviour in the function
receiving the instance via its input parameter.
However.
There is still a need to cover my real world situation which is not
addressed by the available attributes.

I propose an additional attribute of say 'Masks' that is polymorphic.

It has been suggested that having individual scope for the Property Get and
Set would solve the problem. But this gives the impression that writing to
the property is logically corrrect and only restricted by scope.
Whereas 'read only' on the base class property declares the intention that
writing to the property is a nonsense.
The derived class using the proposed 'Masks' attribute indicates a
fundamental change in the property behaviour.

The individual scope on the get set covers the case where writing is
logically sensible but resticted so let's have that too.

regards
Bob

 

[Jay B. Harlow [MVP - Outlook]]

Bob,
I'm not sure if a "Masks" would really solve it either, or if its really
needed. As "Masks" implies that you want to override a sealed
(non-overridable) method, there may be significant valid reasons as to why
the method is not overridable and you would possibly be causing some
unpleasant & unexpected, not to mention very difficult to track down bugs by
overriding it.


What you need to do is make the base method Overridable, thus allowing the
derived method to Override it. Overridable, MustOverride & Overrides is how
you get polymorphic behavior with classes (Implements is how you get it with
Interfaces).

Unfortunately this still does not get you around the "problem" that the
overriding method needs to match the overridable method for read-only,
read-write, or write-only.

I don't know my IL well enough to know if you can have a virtual
(overridable) read-only base property, that is overridden by a read-write
derived property. If you can, this would "solve" your problem without
introducing a keyword.

I've wanted to do something similar with interfaces. The interface has a
read-only property, where as the class implements it via a read-write
property, fortunately you can implement the property such as getting it to
work is easy, I don't know of a similar method with inheritance, short of
using a SetWhatever sub for the setting of the property...

It has been suggested that having individual scope for the Property Get
and
Set would solve the problem.

It's true the VB 2005 (aka Whidbey, due out later in 2005) will support
having different access levels for the Get & Set methods of a property,
however I don't see how that is going to help here per se...

Hope this helps
Jay

 

[Bob]

Hi Jay,
Thanks for your reply.
My problem is physically solved as the base class is only used internally in
my application so it doesn't matter if its interface is tightly spec'd or
not. I have made all necessary properties Read / Write so that the derived
class can over ride them.

I was more interested in seeing if someone from Microsoft would chime in
with regard to language improvement.

Perhaps 'Mask' would need to accompanied with 'Maskable' so that the pair
really form a loosely spec'd version of Overrides and Overridable.

The real world problem is that this is a new app. The base class processes
an incoming data stream internally and interacts with the data layer which
writes the contents of its Read only properties to the database..
A need was later identified to extract the history data out of the old
applications database, different database type and layout but 'processed
data'.
So I figured the easiest way was to derive a class off the base class, pass
the data from the old database into the derived class via the appropriate
properties and leverage the base class's already proven interaction with the
data layer.
I feel this is a valid design decision and I would like to have the tools to
do it legimately.
regards
Bob

 

[Jay B. Harlow [MVP - Outlook]]

Bob,

Perhaps 'Mask' would need to accompanied with 'Maskable' so that the pair
really form a loosely spec'd version of Overrides and Overridable.

Out of curiosity where does Mask & Maskable provide anything more then
Overridable & Overrides do today? I'm not seeing it in the examples you have
given.

I see more value in simply allowing the overriding property to be
read-write, where the base overridable property is read only, rather then
introduce a second "hard to grasp" concept (the first being Shadows) and
another keyword. I can also see benefit in only overriding the get or the
set of the property, rather then requiring both be in the derived class.
Again I do not know if IL & the CLR itself supports this...

properties and leverage the base class's already proven interaction with
the
data layer.

Unit Tests will ensure this: http://www.nunit.org/ or
http://www.csunit.org/index.php

I feel this is a valid design decision and I would like to have the tools
to
do it legimately.

In my experience Refactoring is the tool to change the design.
http://www.refactoring.com/

Especially when "the base class is only used internally in my application".

Hope this helps
Jay