Re: A practical concern (was Re: [PEPr] Comment on RFC::ProtectedMembers)

Hi Hans, I've included a chunk of that text in the proposal, It's definitely a point voters should be aware of. Thanks old chap! ----- Original Message ----- From: "Hans Lellelid" <hans@velum.net> To: "Aidan Lister" <aidan@virtualexplorer.com.au> Cc: "PEAR developer mailinglist" <pear-dev@lists.php.net> Sent: Monday, June 28, 2004 2:08 AM Subject: A practical concern (was Re: [PEPr] Comment on RFC::ProtectedMembers) > I have one [last, hopefully] practical concern about this prefix w/ '_' > business. I don't know why this didn't occurr to me earlier, since I've > made use of this feature: > > Protected properties and methods may be declared public by child classes. > > In this regard 'protected' is like public in terms of the obligations of > the library author. This is completely legitimate too. For example, if > you want to keep your public API small, but allow extending classes to > expose more functionality (which I've done in past w/ Propel, for > example). Or, if you would prefer to access class properties directly > rather than using setter methods, you can redeclare the properties > public in a child class. > > If we prefix protected methods & variables we will be essentially > allowing public members to also be prefixed with '_': > > $o = new MySubClass(); > $o->_wasProtected = 'val'; > $o->_wasProtectedMethod(); > > Is that really what PEAR wants to enable? > > Here's some code to illustrate this: > > <?php > > class Foo { > protected $_var = "Foo's protected var."; > public function show() { > return $this->_var; > } > } > > class Bar extends Foo { > public $_var = "Bar's public var."; > } > > $f = new Foo(); > print "Foo->show() : " . $f->show() . "\n"; > > $b = new Bar(); > print "Bar->show() : " . $b->show() . "\n"; > > $b->_var = "Yippy."; > print "Bar->show() : " . $b->show() . "\n"; > > ?> > > --Hans