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