If a method is public, it can be used from outside, not matter how internal the class is. If its an internal class, and its critical an you don't want users to abuse that method, declare it final. The change is not about preventing developers from using some methods, go for it, you can use any public method. It is about closing points of unexpected inheritance, and leaving places for developers to extend the framework by providing alternative implementations.
As I replied to someone on twitter its best to refactor code to inheritance instead of designing for it. In that sense Symfony2 is the only framework, where Controllers and Models and Views don't require any base class. This way we don't force any developer into our own inheritance trees, leaving most of their code re-usable and framework agnostic. Everzet also posted a fine comparison on twitter: http://twitter.com/everzet/status/45632267107835904 http://twitter.com/everzet/status/45630401347207168 If you spot a case where you want to get ahold of a private property/method, please make your case and we will either tell you how to do it best using existing means, or open up the above-mentioned member to inheritance. When framework developers only use protected methods and don't close classes for inheritance, it is not because they want the framework to be extensible to the very core. For the most part, it is because they are simply lazy to craft proper extension paths. Best, On Fri, Mar 11, 2011 at 3:21 AM, Robert Lemke <[email protected]> wrote: > Hi Lukas, > > On 10 Mrz., 20:34, Lukas Kahwe Smith <[email protected]> wrote: > > > > Why not just put a sentence in the documentation: "protected > > > properties/methos are not part of the API and can be changed any time"? > > > > because that would also not be correct, since we do have places where we > invite users to inherit and reuse methods. > > that's right. What about public methods which are not really meant to > be part of the public API (but need to be public for internal > framework use) – do you have a specific way to warn developers that > they shouldn't use them? > > (see http://robertlemke.de/blog/posts/2011/03/11/protected-vs-private > for our current approach in FLOW3) > > Would be perfect to have a common concept / convention for the bigger > PHP projects and if we find one, we'd gladly refactor our code to meet > it. > > -- > 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
