hiding inherited public member

[Allen Anderson]

Just curious if there is a way to hide a public member inherited from
another class. I know you can 'new' to give it your own version, but
is there a way to make it no longer public period? I would like the
base class version to stay there, just be protected instead. I can't
make the baseclass version protected because there are times when the
baseclass can be used by itself.

[Jeff Louie]

Allen... You may want to reconsider the design. With few exceptions,
protected/public data is discouraged.

// start quote

RESPONSE: [e-mail] (Bjarne Stroustrup), 13 Jun 95

I think that overstates the case against `protected' a bit. here is
the actual quote:

Five years or so later, Mark banned the use of protected data
members in Interviews because they had become a source of bugs:
``novice users poking where they shouldn't in ways that they ought
to have known better than.'' They also seriously complicate
maintenance: ``now it would be nice to change this, do you think
someone out there might have used it?'' Barbara Liskov's OOPSLA
keynote gives a detailed explanation of the theoretical and
practical problems with access control based on the `protected'
notion. In my experience, there have always been alternatives
to placing significant amounts of information in a common base
class for derived classes to use directly. In fact, one of my
concerns about `protected' is exactly that it makes it too easy
to use a common base the way one might sloppily have used global
data.

Fortunately, you don't have to use protected data in C++;
`private' is the default in classes and is usually the better
choice. Note that none of these objections are significant for
protected member functions. I still consider `protected'
a fine way of specifying operations for use in derived classes.
The Design and Evolution of C++, sec13.9.

However, I do consider reliance on protected data a dubious practice
in any language.

// end quote

Regards,
Jeff

I can't make the baseclass version protected because there are times

when
the baseclass can be used by itself.<
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Jason DeFontes]

No matter what you do, you can't prevent someone from doing:

Derived d = new Derived();

Base b = (Base)d;

b.Foo = "not hidden anymore";

-Jason

Allen Anderson wrote:

Just curious if there is a way to hide a public member inherited from
another class. I know you can 'new' to give it your own version, but
is there a way to make it no longer public period? I would like the
base class version to stay there, just be protected instead. I can't
make the baseclass version protected because there are times when the
baseclass can be used by itself.

[Allen Anderson]

Your missing my point. I realize the OOP implications of this and
honestly it doesn't really apply to this situation. The problem I
have is that I have created a nice listview which has an Items class
that is public. I have created a new control (TreeListView) that
inherits from my listview. This is all going very well. The only
catch is that now I have 'Nodes' instead of 'Items' and they are
functionally different. I would therefore like to hide the Items
collection. I'm not sure you can do this with c# (im pretty sure you
can't at this point). It's not something that is going to seriously
hurt or damage my control in any way. It would just be a 'nice to
have'. I want to make it protected instead of private in order to
make that Items collection available to anyone subclassing the
treelist that really wants to get at the underlying framework but
again this isn't really crucial.

On Sun, 16 May 2004 14:09:40 -0700, Jeff Louie <je********@yahoo.com>
wrote:

Allen... You may want to reconsider the design. With few exceptions,
protected/public data is discouraged.

// start quote

RESPONSE: [e-mail] (Bjarne Stroustrup), 13 Jun 95

I think that overstates the case against `protected' a bit. here is
the actual quote:

Five years or so later, Mark banned the use of protected data
members in Interviews because they had become a source of bugs:
``novice users poking where they shouldn't in ways that they ought
to have known better than.'' They also seriously complicate
maintenance: ``now it would be nice to change this, do you think
someone out there might have used it?'' Barbara Liskov's OOPSLA
keynote gives a detailed explanation of the theoretical and
practical problems with access control based on the `protected'
notion. In my experience, there have always been alternatives
to placing significant amounts of information in a common base
class for derived classes to use directly. In fact, one of my
concerns about `protected' is exactly that it makes it too easy
to use a common base the way one might sloppily have used global
data.

Fortunately, you don't have to use protected data in C++;
`private' is the default in classes and is usually the better
choice. Note that none of these objections are significant for
protected member functions. I still consider `protected'
a fine way of specifying operations for use in derived classes.
The Design and Evolution of C++, sec13.9.

However, I do consider reliance on protected data a dubious practice
in any language.

// end quote

Regards,
Jeff

I can't make the baseclass version protected because there are times

when
the baseclass can be used by itself.<
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Jeff Louie]

Allen... Please note that my comment is directed toward a
protected/public
data member, not a public property. When I _had_ to deny access to a
public
property, I have resorted to containment.

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Jon Skeet [C# MVP]]

Jeff Louie <je********@yahoo.com> wrote:

Allen... Please note that my comment is directed toward a
protected/public data member, not a public property. When I _had_ to
deny access to a public property, I have resorted to containment.

I think you mean "field" rather than "member" then. Properties, methods
and fields are *all* members. Discouraging public members would make it
pretty hard for anything to call anything else!

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[cody]

The only way to do this is to throw an NotImplementedException or
InvalidOperationException or similar by a call to the Items property.

--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu || http://www.deutronium.tk
"Allen Anderson" <al***@sparkysystems.com> schrieb im Newsbeitrag
news:la********************************@4ax.com...

Your missing my point. I realize the OOP implications of this and
honestly it doesn't really apply to this situation. The problem I
have is that I have created a nice listview which has an Items class
that is public. I have created a new control (TreeListView) that
inherits from my listview. This is all going very well. The only
catch is that now I have 'Nodes' instead of 'Items' and they are
functionally different. I would therefore like to hide the Items
collection. I'm not sure you can do this with c# (im pretty sure you
can't at this point). It's not something that is going to seriously
hurt or damage my control in any way. It would just be a 'nice to
have'. I want to make it protected instead of private in order to
make that Items collection available to anyone subclassing the
treelist that really wants to get at the underlying framework but
again this isn't really crucial.

On Sun, 16 May 2004 14:09:40 -0700, Jeff Louie <je********@yahoo.com>
wrote:

Allen... You may want to reconsider the design. With few exceptions,
protected/public data is discouraged.

// start quote

RESPONSE: [e-mail] (Bjarne Stroustrup), 13 Jun 95

I think that overstates the case against `protected' a bit. here is
the actual quote:

Five years or so later, Mark banned the use of protected data
members in Interviews because they had become a source of bugs:
``novice users poking where they shouldn't in ways that they ought
to have known better than.'' They also seriously complicate
maintenance: ``now it would be nice to change this, do you think
someone out there might have used it?'' Barbara Liskov's OOPSLA
keynote gives a detailed explanation of the theoretical and
practical problems with access control based on the `protected'
notion. In my experience, there have always been alternatives
to placing significant amounts of information in a common base
class for derived classes to use directly. In fact, one of my
concerns about `protected' is exactly that it makes it too easy
to use a common base the way one might sloppily have used global
data.

Fortunately, you don't have to use protected data in C++;
`private' is the default in classes and is usually the better
choice. Note that none of these objections are significant for
protected member functions. I still consider `protected'
a fine way of specifying operations for use in derived classes.
The Design and Evolution of C++, sec13.9.

However, I do consider reliance on protected data a dubious practice
in any language.

// end quote

Regards,
Jeff

I can't make the baseclass version protected because there are times

when
the baseclass can be used by itself.<
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[cody]

Another way would be to derive your control from UserControl and put a
ListView/TreeView/Whatever in it.

--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu || http://www.deutronium.tk
"Allen Anderson" <al***@sparkysystems.com> schrieb im Newsbeitrag
news:la********************************@4ax.com...

Your missing my point. I realize the OOP implications of this and
honestly it doesn't really apply to this situation. The problem I
have is that I have created a nice listview which has an Items class
that is public. I have created a new control (TreeListView) that
inherits from my listview. This is all going very well. The only
catch is that now I have 'Nodes' instead of 'Items' and they are
functionally different. I would therefore like to hide the Items
collection. I'm not sure you can do this with c# (im pretty sure you
can't at this point). It's not something that is going to seriously
hurt or damage my control in any way. It would just be a 'nice to
have'. I want to make it protected instead of private in order to
make that Items collection available to anyone subclassing the
treelist that really wants to get at the underlying framework but
again this isn't really crucial.

On Sun, 16 May 2004 14:09:40 -0700, Jeff Louie <je********@yahoo.com>
wrote:

Allen... You may want to reconsider the design. With few exceptions,
protected/public data is discouraged.

// start quote

RESPONSE: [e-mail] (Bjarne Stroustrup), 13 Jun 95

I think that overstates the case against `protected' a bit. here is
the actual quote:

Five years or so later, Mark banned the use of protected data
members in Interviews because they had become a source of bugs:
``novice users poking where they shouldn't in ways that they ought
to have known better than.'' They also seriously complicate
maintenance: ``now it would be nice to change this, do you think
someone out there might have used it?'' Barbara Liskov's OOPSLA
keynote gives a detailed explanation of the theoretical and
practical problems with access control based on the `protected'
notion. In my experience, there have always been alternatives
to placing significant amounts of information in a common base
class for derived classes to use directly. In fact, one of my
concerns about `protected' is exactly that it makes it too easy
to use a common base the way one might sloppily have used global
data.

Fortunately, you don't have to use protected data in C++;
`private' is the default in classes and is usually the better
choice. Note that none of these objections are significant for
protected member functions. I still consider `protected'
a fine way of specifying operations for use in derived classes.
The Design and Evolution of C++, sec13.9.

However, I do consider reliance on protected data a dubious practice
in any language.

// end quote

Regards,
Jeff

I can't make the baseclass version protected because there are times

when
the baseclass can be used by itself.<
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Allen Anderson]

yea, I've decided to go in a different direction with my solution to
this. I'm going to write a treeview control (pretty easy actually) to
pair with my listview. Then I'm going to do a treelist by containment
of both.

On Sun, 16 May 2004 21:41:49 -0700, Jeff Louie <je********@yahoo.com>
wrote:

Allen... Please note that my comment is directed toward a
protected/public
data member, not a public property. When I _had_ to deny access to a
public
property, I have resorted to containment.

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!