TITLE: Is protected data a bad idea?

PROBLEM: jborkole@jpmorgan.com

 In The Design and Evolution of C++ Stroustrup discusses access
 specifiers. There are 3 levels, public, protected and private. 

 ... 

 The interesting thing is that the book states that Mark banned the use of 
 protected data members as they were a source of bugs. ie allowing subclasses
 to access a classes member data caused bugs! Stroustrup also
 states that they appear to cause maintenance problem. He states that private
 is usually the better choice. He wishes he had not introduced the protected
 concept.
 

RESPONSE: bs@research.att.com (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.