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... In my opinion having to copy the code of a class to add a small feature is very bad for maintainability (yes, the framework user's, not the framwork developer's). In case of a security problem, this leads to sites patched late or not at all. Why not just put a sentence in the documentation: "protected properties/methos are not part of the API and can be changed any time"?
Am 10.03.2011 19:52, schrieb Richtermeister: > Hi all, > > interesting read. An example that comes to mind are bind() vs. > doBind(), and save() vs. doSave() in the object form classes, where > only the do* methods are supposed to be overriden, yet that nugget of > wisdom is only in the phpdoc comment and is easily overlooked, so lots > of code I see has the bind() & save() methods overridden directly. > > +1 for private. > > Daniel > > > > > On Mar 10, 9:29 am, ericclemmons <[email protected]> wrote: >> +1 Lukas + Jonathan's comments, specifically in regards to reducing BC >> breaks and reducing extension points to a manageable number. >> >> So, the code in the future will have a lot less of manipulation of >> "$this->fooObject", but rather manipulating "$this->getFooObject()" >> because of the constrained API? >> >> You're right. Down the line, forcing a gateway to object properties >> will prove beneficial, especially if the getter does something more >> than simply returning the property value, such as lazy-loading an >> object or dispatching an event. >> >> Thanks for the clarification, fellows! >> >> On Mar 10, 11:10 am, Lukas Kahwe Smith <[email protected]> wrote: >> >>> On 10.03.2011, at 18:05, Jonathan Wage wrote: >> >>>> 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. >> >>> exactly ... this change doesnt mean "no inheritance" .. it means carefully >>> guided and designed inheritance extension points. less guessing about which >>> of the 3-5 different possible ways to do something to choose. more >>> consistency across Bundles follows naturally. >> >>> as a result of stopping this gigantic kitten slaughter we might end up with >>> a kitten plague ;) >> >>> 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
