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
12  1414 
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
"Bob" <bo*@nowhere.com> wrote in message
news:e9****************@tk2msftngp13.phx.gbl... 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
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
"Bob" <bo*@nowhere.com> wrote in message
news:e9****************@tk2msftngp13.phx.gbl... 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
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).
--
Scott Swigart http://blog.swigartconsulting.com
"Bob" <bo*@nowhere.com> wrote in message
news:e9****************@tk2msftngp13.phx.gbl... 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
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).
--
Scott Swigart http://blog.swigartconsulting.com
"Bob" <bo*@nowhere.com> wrote in message
news:e9****************@tk2msftngp13.phx.gbl... 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
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
"Bob" <bo*@nowhere.com> wrote in message
news:e9****************@tk2msftngp13.phx.gbl... 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
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
"Bob" <bo*@nowhere.com> wrote in message
news:e9****************@tk2msftngp13.phx.gbl... 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
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" <bo*@nowhere.com> wrote in message
news:Om****************@TK2MSFTNGP15.phx.gbl... 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
"Bob" <bo*@nowhere.com> wrote in message
news:e9****************@tk2msftngp13.phx.gbl... 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
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" <bo*@nowhere.com> wrote in message
news:Om****************@TK2MSFTNGP15.phx.gbl... 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
"Bob" <bo*@nowhere.com> wrote in message
news:e9****************@tk2msftngp13.phx.gbl... 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
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]" <Ja************@msn.com> wrote in message
news:O5****************@tk2msftngp13.phx.gbl... 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" <bo*@nowhere.com> wrote in message
news:Om****************@TK2MSFTNGP15.phx.gbl... 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
"Bob" <bo*@nowhere.com> wrote in message
news:e9****************@tk2msftngp13.phx.gbl... 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
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]" <Ja************@msn.com> wrote in message
news:O5****************@tk2msftngp13.phx.gbl... 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" <bo*@nowhere.com> wrote in message
news:Om****************@TK2MSFTNGP15.phx.gbl... 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
"Bob" <bo*@nowhere.com> wrote in message
news:e9****************@tk2msftngp13.phx.gbl... 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
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
"Bob" <bo*@nowhere.com> wrote in message
news:eI****************@TK2MSFTNGP12.phx.gbl... 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]" <Ja************@msn.com> wrote in message
news:O5****************@tk2msftngp13.phx.gbl... 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" <bo*@nowhere.com> wrote in message
news:Om****************@TK2MSFTNGP15.phx.gbl... > 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
>
>
>
> "Bob" <bo*@nowhere.com> wrote in message
> news:e9****************@tk2msftngp13.phx.gbl...
>> 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
>>
>>
>>
>>
>>
>>
>
>
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
"Bob" <bo*@nowhere.com> wrote in message
news:eI****************@TK2MSFTNGP12.phx.gbl... 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]" <Ja************@msn.com> wrote in message
news:O5****************@tk2msftngp13.phx.gbl... 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" <bo*@nowhere.com> wrote in message
news:Om****************@TK2MSFTNGP15.phx.gbl... > 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
>
>
>
> "Bob" <bo*@nowhere.com> wrote in message
> news:e9****************@tk2msftngp13.phx.gbl...
>> 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
>>
>>
>>
>>
>>
>>
>
>
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Dave |
last post by:
What is the expected output of this program and why???
#include <iostream>
using namespace std;
class base
{
|
by: Maurice Termeer |
last post by:
Hi, suppose i've got this:
class a {
public:
int n;
};
class b : public a {
public:
};
|
by: verec |
last post by:
One problem I've come accross in designing a specific version of auto_ptr
is that I have to disntiguish between "polymorphic" arguments and "plain" ones,
because the template has to, internally,...
|
by: verec |
last post by:
Last week I asked here how I could detect that a T was polymorphic, and
received
very thoughtful and useful replies that I used straight away. Thanks to all who
answered.
This week, it turns...
|
by: Mr. Ed |
last post by:
I have a base class which has about 150 derived classes. Most of the
derived classes are very similar, and many don't change the base class
at all. All the derived classes have a unique factory...
|
by: James Fortune |
last post by:
In response to different users or situations (data context) I
transform the appearance and characteristics of Access Forms through
code. This seems to fit in with the idea of polymorphism. Do...
|
by: Jedrzej Miadowicz |
last post by:
I have a problem when using ISynchronizeInvoke.BeginInvoke with polymorphic
parameters. It seems that if I try to call BeginInvoke and in the array of
parameters place an object that's derived from...
|
by: Bob |
last post by:
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...
|
by: Arindam |
last post by:
#include <cstdio>
struct Test {
void bar() {
foo();
}
private:
virtual void foo() {
printf("Test\n");
}
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
