Re: how to mark protected properties?

Hi Alan, ... unconvinced :) Alan Knowles wrote:

Sounds like someone paid too much attention in the java lessons.. - perhaps certain components of a banking applications where encapsulation is essential this theory holds true, but for a highly re-usable, easy to understand lightweight libraries, encapsulation has to be treated with a high degree of restraint.

I would say that it is precisely for re-usable applications that encapsulations makes the most sense. To clarify, what I mean by "re-usable" is that many people with many different project goals need to be able to use & re-use your class.

A number of my classes attempted to ecapsulate data early on, and over time people have requested access to those variables, most of the time it was not critical to have them private in anyway.. - so they just became public. This has happened in a number of other PEAR classes I've used. - the author made something private, that didnt need to be, and occasionally, it ended up more efficient to either extend/ignore the private or just fork the code.

Why were people requesting direct access to variables...? Here I'll take what I assume is an unpopular stance in PHP & say that more crap code has been written for the sake of negligible performance gain. Perhaps there are benchmarks out there that would change my mind. This is a extremely limiting move, IMO. Where before simple extension could allow the user to add hooks for setting/getting values and allow you the maintainer to change your code drastically internally without sacrificing BC, now you are locked in to a specific class design with limited exstensibility. ...No more user hooks for setting/reading & you can no longer control the internal state of your object.

I have a suspician this situation is going to get far worse with PHP5, if library authors are going to insist on using private and protected keywords alot, then when it comes to reuse the code, and it doesnt quite fit the requirements, rather than a workaround of extend / access privates, a full copy paste replacement is going to become more common. (hence making these kludges even worse to maintain than before..) Personally I think we should ban Protected :) - as it enforces the extension pattern over a (whatever that other one is) pattern. on the end user..

Yes & ban Exceptions (isn't PEAR planning on doing that anyway?) because they encourage error catching ... But seriously, why would you want to discourage the extension pattern (seems funny to call that a pattern since it's so fundamental to OO design)? A public API combined with the extension "pattern" are what provide the contract and the flexibility for others using your classes. Seems rather silly to have to make a point like that on PEAR, which is replete w/ classes that make heavy use of OO design & patterns. You can always declare a class 'final' if it really shouldn't be extended. I do sure hope that PHP5 encourages things like data encapsulation. PHP is certainly becoming more like the big managed languages (Java, C#, whatever), but that's driven by popular demand (certainly not by any natural tendency of the PHP/ZE code structure). Hans