+1 I agree with your comments... otherwise it'll end up just like PHP ;)
On Wednesday, January 9, 2013 1:04:51 AM UTC+13, Daniel A.Tiecher wrote: > > 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
