I must say, that I didn't read the concrete proposal completely yet, but I prefer to have things clean, before it is too late (here: Before "the world" gets used to "the ugly way", so one cannot fix it anymore, without heavy impact). Also 2.3 should be the LTS, so I guess it's a good idea to make it a clean LTS
So I'd like to say: +0.5 :) (or +1, if it must be an integer :D) 2013/1/8 Cameron Junge <cameron.ju...@sella.co.nz> > +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<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<https://github.com/symfony/symfony/issues/6453> >>>> >>>> [2] >>>> https://twitter.com/**webmozart/status/**288246362334691328<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 > > > -- github.com/KingCrunch -- -- 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
