You have to also consider what this change forces us to do. Instead of just solving the inheritance and extension problem by whoring out our API and opening everything up we will have to specifically design for inheritance and extension points. This will result in a much better experience for everyone .You will have clear ways to extend and inherit things that are designed for it, and we will have a much easier time maintaining and evolving the internals of the code because we won't be breaking BC every move we make. It may be hard to see now but fruits from this change will definitely be apparent later in the life of Symfony2.
- Jon On Wed, Mar 9, 2011 at 7:23 PM, ericclemmons <[email protected]> wrote: > 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 > -- Connect with me on *http://twitter.com/jwage* <http://twitter.com/jwage> and http://about.me/jwage to keep in touch. -- 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
