People browsing and not casting their vote as +1 or -1 are probably +0 on this one, that's why only 4 votes were cast, in my opinion at least. :)
After thinking about the issue for a while I am +1 on this one, because even though we have some BC break in the process, in the long run and in the name of consistency with other Symfony components that's the better option. We shouldn't be looking back a year from now and resenting about the fact the Form component has a different and somehow chaotic structure compared to the other Symfony components. Em segunda-feira, 7 de janeiro de 2013 19h58min47s UTC-2, Victor Berchet escreveu: > > +1 from Lee Conlin on Twitter - > https://twitter.com/hades200082/status/288362992314224640 > > 120+ views, 4 votes, what's wrong ??? > > On Monday, January 7, 2013 1:06:25 PM UTC+1, Victor Berchet wrote: >> >> We use PHP namespaces in Symfony2 for 2 main reasons: >> >> 1) Prevent class name collisions >> 2) Organize the code by functionality >> >> While most Symfony2 components (the ones that support a large enough set >> of functionalities) respect both principles, I think that the Form >> component only respect the first principle. >> To keep consistency across components, I think that updating the Form >> component to follow the second principle would be good. >> >> I have opened an issue on symfony/symfony[1] for that. >> >> Currently the top level directory (=namespace) contains a bunch of >> unrelated classes: extension, renderer, transformer, builders, event, >> guesser, view, type, ... >> I would love to see the classes grouped in different namespaces to ease >> the understanding and the maintenance of the Form component. >> >> 2.3 will be our last chance to do this modification as it will be the >> first LTS release and we should refrain from breaking BC after that. >> If we don't do before then (6 more months) we will have to live with it >> forever and any added classes will be added to the TLD. >> >> Now, there's one drawback, it *will* break BC as the FQCN will change. >> >> On the other hand, there has already been countless BC breaks in the Form >> component and I fail to see how this particular one would be worse than >> other. >> The other thing you have to keep in mind is that most pending Form PRs >> are created with "Backwards compatibility break: no" because we keep legacy >> classes for now, >> but all the legacy classes are planned to be removed in 2.3 so in the end >> it should be "Backwards compatibility break: yes, in 2.3". >> >> Bernhard does not consider (re)organizing the TLD as worth for 2.3, I do. >> However he will consider this if enough people think it is important[2], so >> please let us know what you think about this change: >> >> - +1 = I think it could help, >> - -1 = I don't want more BCs, the current situation is fine with me, >> - 0 = I really don't care. >> >> Bernhard, I would like to take the opportunity of this post to let you >> know that I truly think that the Form component is great and I really >> appreciate all the efforts you put in it to make it even better, >> even if like I have said (too many times ?) lately that I would prefer to >> see the 100+ pending issues solved before adding new features. >> >> Cheers, >> Victor >> >> [1] https://github.com/symfony/symfony/issues/6453 >> [2] https://twitter.com/webmozart/status/288246362334691328 >> > -- -- If you want to report a vulnerability issue on Symfony, please read the procedure on http://symfony.com/security You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
