Public to Private

[Ajay Martin]

Why would it be reasonable for someone to argue that it is incorrect to
allow a public member inherited from a public base class to be redefined as
private?

[Victor Bazarov]

Ajay Martin wrote:

Why would it be reasonable for someone to argue that it is incorrect
to allow a public member inherited from a public base class to be
redefined as private?

Could be due to the same views that cause people to continue the
discussions whether 'square' should inherit from 'rectangle' or
vice versa, and whether it should be done publicly or privately.

C++ is not an OO language. It's a language with elements of OOP.
Live and let live, I say. If somebody wants to argue against
redeclaring a public inherited member as private, let them prove
their point. But don't stop them from arguing.

Why would it be reasonable for a dog to lick its ...? Ask the
dog.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Phlip]

Ajay Martin wrote:

Why would it be reasonable for someone to argue that it is incorrect to
allow a public member inherited from a public base class to be redefined as
private?

Firstly, it's "reasonable " in our industry for anyone to argue
anything. The ability to propose and debate techniques is a critical
aspect of being a software engineer.

Now discuss whether to actually do it.

There's no syntactic reason not to do that.

The technical reason is "principle of least surprise". The Liskov
Substitution Principle implies that two objects that share an interface
should share it semantically, not just syntactically. Client code,
calling those objects, shouldn't be able, in the normal course of the
client's activities, to tell the difference between the two items.

There are other ways to use object polymorphically besides pointers or
references to base classes. If you use one, such as generics, you might
surprise a client, when a public member suddenly becomes private.

So don't do that, and add it to the list of things your team knows not
to do.

--
Phlip

[Salt_Peter]

Ajay Martin wrote:

Why would it be reasonable for someone to argue that it is incorrect to
allow a public member inherited from a public base class to be redefined as
private?

Lets suppose that the derived class needs access to the public member
but protects the user of the class by not providing public access to
it. Why should that be forbidden? Why should a critical public member
be forced to expose itself? Its called encapsulation, is it not?
So reasonable it is not - its counter-productive. Its like saying that
deriving from base is a waist of time.

Now, if he/she argued that a virtual member function was made private,
then the arguement may hold. Although, even that could be warranted in
the case that the inheritance scheme is less than perfect.

[Pete C]

Ajay Martin wrote:

Why would it be reasonable for someone to argue that it is incorrect to
allow a public member inherited from a public base class to be redefined as
private?

For me, it would be illogical and potentially confusing (I don't say
"incorrect" ) to do this, because the member may still be changed via a
pointer (or reference) to the base class type. So the derived class
will have to treat the member as though it were public anyway.

So to redefine the member as private won't add any meaningful access
control, and will be counter-intuitive for users of the derived class.
I can't think of a good reason to do it, but it's best to keep an open
mind in case a good reason turns up later.

Example:

struct Base
{
int member;
};

struct Derived : public Base
{
private:
using Base::member;
};

int main()
{
Derived derived;

// This is illegal: "member" is private in Derived
derived.member = 1;

// But access via pointer-to-base-class is OK!
Base *pb = &derived;
pb->member = 1;
}

[Alf P. Steinbach]

* Pete C:

>
So to redefine the member as private won't add any meaningful access
control, and will be counter-intuitive for users of the derived class.
I can't think of a good reason to do it, but it's best to keep an open
mind in case a good reason turns up later.

In the case of a spaghetti system it's sometimes useful to replace

class Something: public Spaghetti
{
public:
...
};

with

class Something: protected Spaghetti
{
public:
Spaghetti& asSpaghetti() { return *this; }
Spaghetti const& asSpaghetti() const { return *this; }

using SpaghettiClass: :memberD;
using SpaghettiClass: :memberZ;
...
};

in order to ascertain what's actually /used/ (by Something's client
code) of all that stuff inherited from Spaghetti.

Of course one may end up finding that most of the spaghetti stuff is
used, in which case the gain is only knowing that class Something is not
a good place to start cleaning up the system, and any insights come by
while adding necessary 'using' clauses to get the thing to compile.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Victor Bazarov]

Pete C wrote:

Ajay Martin wrote:

>Why would it be reasonable for someone to argue that it is incorrect
to allow a public member inherited from a public base class to be
redefined as private?

For me, it would be illogical and potentially confusing (I don't say
"incorrect" ) to do this, because the member may still be changed via a
pointer (or reference) to the base class type. So the derived class
will have to treat the member as though it were public anyway.

So to redefine the member as private won't add any meaningful access
control, and will be counter-intuitive for users of the derived class.
I can't think of a good reason to do it, but it's best to keep an open
mind in case a good reason turns up later.

Example:

struct Base
{
int member;
};

struct Derived : public Base
{
private:
using Base::member;
};

int main()
{
Derived derived;

// This is illegal: "member" is private in Derived
derived.member = 1;

// But access via pointer-to-base-class is OK!
Base *pb = &derived;
pb->member = 1;
}

You misread the question. It contains the term "redefined" . You just
re*declared* 'member' in 'Derived', you didn't *redefine* it. And for
what it's worth, everybody else seemed to think the question was about
member functions, not data.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask