Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!att!cbnewsm!stanl
From: stanl@cbnewsm.ATT.COM (stanley.b.lippman)
Newsgroups: comp.lang.c++
Subject: Re: conflict
Summary: ``access declaration'' constraints in 2.0
Message-ID: <1479@cbnewsm.ATT.COM>
Date: 30 Jun 89 14:26:55 GMT
References: <1971@ektools.UUCP>
Distribution: usa
Organization: AT&T Bell Laboratories
Lines: 31

In article <1971@ektools.UUCP>, randolph@ektools.UUCP (Gary L. Randolph) writes:
	> 
	> OK, which is it?

  **> Ira Pohl's description is correct for Release 1.*

      The behavior was changed in 2.0 to make encapsulation 
      and subtyping more secure.

      The description in the C++ Primer is correct for Release 2.0,
          and is described in section 11.3 of the Reference Manual
          cited by Bjarne in an earlier message.

	> Pohl's text (pg. 143):
	> 
	>    "If a member is transmitted to its derived class as private, this
	>    can be altered to public or protected, as in the following:
	... 
	> In the same manner, a publicly transmitted member can be explicitly
	> converted to private or protected."
	> 
	> -------------------***--------------------
	> 
	> NOW, Lippman's text (pg. 318, 319):
	> 
	> "The derived class can maintain the inherited member's access level
	> only.  The access level cannot be made either more or less
	> restrictive that the level originally specified within the base
	> class.  It is illegal, for example, to declare the protected
	> ZooAnimal class member onDisplay within a public section of Rodent
	> or to declare inform() within a protected section."