If you can extend the class, then you should be using `protected`. Private, IMO, isn't entirely necessary and is only being used to try and stop bad practices of those utilizing an open-source product.
Symfony is well designed, but there's no need to bind the hands of whoever chooses to extend code for their own purposes. I understand both sides to this debate. In the same way that we use getters/setters to avoid direct access to internals of a class via public properties, we're now inheriting classes to go the same route when they should share ownership. To me, changing "protected" to "private" is spending cycles solving a problem that either doesn't really exist, or isn't the framework's problem to solve. My $0.02 & change :) -- Eric Clemmons On Mar 9, 4:19 pm, Bulat Shakirzyanov <[email protected]> wrote: > This change is for the best. > > For people that disagree, read up > onhttp://en.wikipedia.org/wiki/Open/closed_principle > <http://en.wikipedia.org/wiki/Open/closed_principle> > <http://en.wikipedia.org/wiki/Open/closed_principle>Allowing all properties > and methods to be hijacked in subclasses and allowing subclass anything > opens the system to modification, as any of the core system behavior can be > changed. > The correct approach is to provide contracts for extension (interfaces) and > concrete closed implementations that are well-tested and work, and can be > changed internally at any time, without breaking user-land code that > interacts with them (think refactoring). > > If user-land code relies on some internal behavior however, the whole system > is much more error prone with any change to the core class, as it ripples > through all of its descendants. > > My advice to all framework users is to provide alternative implementations > of pre-defined interfaces, instead than relying on overloading of core > classes. > Same applies to mocking - mock interfaces and not actual implementations. > > Final and private are underused in PHP, which is the result of programmers > not thinking of providing explicit ways to extend their framework. Instead > of defining extension points, they simply leave the whole framework open to > modification, which leads to unexpected behavior. The fact that methods and > properties are becoming declared as private means that the framework is in > the stage of its maturity, where we think of opening legit ways for its > extension, while eliminating possibility of hacks. > > Best, > > > > > > > > > > On Wed, Mar 9, 2011 at 5:42 AM, Martin Hasoň <[email protected]> wrote: > > For API is only public visibility (see > >http://api.symfony-reloaded.org/master/). Protected visibility is for all > > others. Private visibility is only for very very special method. Public > > visiblity is for user, protected visibility is for programmer and private > > visibility is for black box. For example framework Django doesn't have a > > private method. > > > -- > > If you want to report a vulnerability issue on symfony, please send it to > > security at symfony-project.com > > > You received this message because you are subscribed to the Google > > Groups "symfony developers" group. > > To post to this group, send email to [email protected] > > To unsubscribe from this group, send email to > > [email protected] > > For more options, visit this group at > >http://groups.google.com/group/symfony-devs?hl=en > > -- > *Bulat Shakirzyanov* | Software Alchemist > > *a: *about.me/avalanche123 > *e:* [email protected] -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
