Re: how to mark protected properties?

Hans Lellelid wrote:

Hi Alan, ... unconvinced :) i wouldnt have expected less :)

I would say that it is precisely for re-usable applications that ................................................^^^^^^^^^^^^^^^......

I'm not sure if that was deliberate or accidental, but that was part of the point, for applications, and applicaiton specific libraries, that have a specific goal, then encapuslation may help considerably. However, I was getting at the fact that, with libraries like PEAR, you rarely know how or what the end user wishes to do with your class, by introducing artificial barriers you are reducing the chances that it will get re-used, or spawning a slew of alternatives to get around these barriers.

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. 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. setters and getters are a performance bottleneck if used alot. Personally I dont like them that much force me to wade throught a pile of shit (loads of getters/setterrs), to find the diamond (the core that actually does something).

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.

Reminds me of the old adage about programmers who design for flexibility in their code, and 20 years later realize that no-one ever used it.. Flexibility usually gets built in by re-factoring based on real problems.

Yes & ban Exceptions (isn't PEAR planning on doing that anyway?) because they encourage error catching ... If Only we could :)

If there was a concensus on the fact that exceptions are evil, or gods gift, it would be easy, but as you can read on the internet, the only conclusion that can be reached is that Exceptions have just as many advantages and disadvantages as Error returns. That said, from what I seen, exceptions as a replacement for PEAR_ERROR_DIE, seem to make some sense. (but as I've been finding, I've been converting _DIE to _RETURN recently in alot of code, so even then, it is very blurry... ) 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)? I dont want to discourage extension pattern, I would rather class designers consider the fact that the extension is a very 'tightly' coupled pattern, where as it is often usefull to 'loosely' couple libraries like PEAR, so when Amazing_Lib2 comes out, which breaks BC, and operates in a different way, It's easier to integrate.

Hans

-- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.com