jimad@microsoft.UUCP (Jim ADCOCK) (05/01/90)
In article <6917@odin.corp.sgi.com> shap@sgi.com writes: >It's been my experience that is is almost always wrong for a member to >be private. Very few members of a class should in practive be private >rather than protected, and when they should be, it probably should be as >a specific consequence of programmer statement. This contradicts my experience. I'd claim that using "protected" is the moral equivalent to declaring your children "friends." Isn't this just another statement that inheritence is more important than encapsulation? --In which case, I disagree, I believe encapsulation is the more important property.
neal@druhi.att.com (XGPB30000-McBurnettND(DR9225)289) (05/03/90)
In article <6917@odin.corp.sgi.com>, shap@thebeach.wpd.sgi.com (Jonathan Shapiro) writes: > The point of which is, isn't it time to consider making 'protected' be > the default state at the top of a class, rather than 'private?' I > believe that having private as the default is an artifact of the > language versions that existed before the protected keyword. I'm not sure what I think of your suggestion that protected members should be used more often than private members. Whether or not that is the case, I definitely think we should encourage people to put public members first in their classes. This makes it easier for the most important customer of the class definition, the customer, to see what the public interface is. While I know that this could be done by using a "struct", I think it is clearer to use a "class" and put the keyword "public:" at the top of the class. This idea was the subject of a paper by Peter Kirslis at the first USENIX C++ conference. I also think it would be a bad idea to modify the default semantics of the language in a way which might break existing code. -Neal McBurnett // AT&T Bell Labs, Denver // neal@druhi.ATT.COM,att!druhi!neal'