Re: how to mark protected properties?

Hi again, Alan Knowles wrote:

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.

Yes, it was accidental, but I wouldn't say Freudian :) I meant libraries, or tools, things that stand alone, have versions and are packaged & distributed. Perhaps we are arguing two ends to the same goal. I believe that extension and encapsulation allows more flexibility because you as package maintainer are only obligated to preserver your API -- everything else can change (e.g. introducing internal caching, changing prop names, combining properties into collections, etc.). It sounds like your perspective is that you want to keep it simple so that people can muck easily with your code. Perhaps that also achieves flexibility, but it at the cost of maintainablility. With the encapsulate/extend model upgrading to your newest Foo2 baseclass won't break any of the using code (assuming API remains consistent -- which is a lot easier when you don't introduce properties).

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).

Yeah, they certainly add some overhead, but IMO that layer of abstraction between a class & its properties is not only good practice but very useful in terms of the hooks it provides. I guess API docs might help in your quick-glance-now-i-understand quest; I don't know what else to say to that. Yes, methods do take up lines of code :)

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.

Sure, but I'm not arguing from a purely theoretical perspective. I'm arguing from having taken advantage on numerous occasions of encapsulation/extension -- for example, deciding that I want to store serialized object in a db row & overriding a setter method to handle the serialization, or adding validation to overridden setter methods, or returning default values from overridden accessor methods, etc. It probably depends on the purpose of the library. I'm not trying to convert anyone to the ideas of encapsulation & extension, but I'd say that for my purposes it provides flexibility that isn't available in (whatever the alternative is called).

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... )

Replacing PEAR_ERROR_DIE with Exceptions only makes sense if you're going to assume that calling code is not going to catch them. Defeats the entire point of Exceptions -- and I think calling code that does not catch Exceptions (from methods marked to throw them) deserves a big E_FATAL smack. The only place where I see a bit of a "?" in the Exception world is how to handle E_WARNING. Probably trigger_error() (or PEAR::raiseError(), I guess) still makes sense for that.

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.

We just disagree on what it means to loosely couple, then :) In your model, loose coupling means building a class that someone has to open up and edit if they want to change the behavior. I see that as a customization that extremely tightly coupled to not only that class, but to a specific no-longer-upgradeable version of the class. In the extension model it means building a class that someone can simply extend to change any of the behavior -- w/o making it impossible to upgrade the base class to fix future bugs, etc. But perhaps I miss your point here? Anyway, to each his own. I feel (and probably look) dumb arguing for basic OO design principles. I like OO, pattern-rich design. I also like Java and C#. I feel happy when things plug in & work and when I can make the most drastic behind-the-scenes changes with the least amount of code rewrite. But your code will always be faster if you access properties directly. And there'll be fewer methods to have to look through to see the guts of the class. Thankfully PHP now (5) provides the ability for both of us to implement our preferred design pattern. :) Hans