This change is for the best. For people that disagree, read up on http://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
