On 09.03.2011, at 10:16, Henrik Bjornskov wrote: > This is essentially killing inheritance for thoose classes. This means that > the framework can only be extended in the ways that core devs want. So if i > wanted to readd the request format magic for my projects i wouldnt be able to > do that.
Its a question of maintainability. We want to provide a reliable API. By making everything protected we basically have to maintain a very large API. Worse yet, the user has no clue what extension points we recommend and which we do not. The end result is that you quickly cannot change anything anymore in the core, since users will use various different extension points to achieve the same. Now in the past I have also been violently opposed to the above practice. However, these days we have several benefits: - git makes it easy to fork - git makes it easy for others to contributes patches to open up API's in specific places - even if for some reason the patch is not accepted, with git its easier to keep your custom fork in sync The other alternative is breaking BC in minor releases (aka 2.1) so I think going to private by default is the better approach. Again on a case by case basis we will then open up the API for inheritance. 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
