Ajay said:
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.