For the most part, isn't it safe to assume that for each property, there will likely be an appropriate getter/setter?
Classes where properties are internally tracking state, caches, etc., may not have a public accessor method for such granular, internal data, but that would be one of those situations where opening up the API for extension purposes may make sense. Great discussion, btw. On Mar 10, 1:34 pm, Lukas Kahwe Smith <[email protected]> wrote: > On 10.03.2011, at 20:26, Georg wrote: > > > Yes, interesting discussion. > > What I understood is that symfony2 is such a sophisticated framework > > that every possible use case is already taken care of, and because of > > that everything should be private/final. If you are sure that's the case... > > no we are not sure that this is the case. so we will review requests to open > the API on a case by case basis. we are just reversing from defaulting to > protected to defaulting to private. > > > 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. > > regards, > Lukas Kahwe Smith > [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
