-0 I don't think the current structure is a big deal, but then I'm biased, since I created it.
Also the "countless number of BC breaks" is in reality a not so huge number of deprecations that will only affect people (in terms of BC) as of 2.3. One restructural proposal that goes easy with BC breaks (because most moved classes aren't used by the common user anyway, except for AbstractType and AbstractTypeExtension) is shown in https://gist.github.com/1bfc53c57291f8e44d93. -- Bernhard Schussek Blog: http://webmozarts.com Twitter: http://twitter.com/webmozart 2013/1/7 Matt Robinson <m...@lazycat.org> > 0. > > Well, 0.5, just to be awkward :). If BC's going to break substantially > anyway (which afaik, it's not, so ignore the rest of this sentence), we > should take the opportunity to reorganise the code purely as a matter of > taste, to make it more consistent with the other Symfony components. > > I don't think it's particularly fair to say "there has already been > countless BC breaks in the Form component" either. Hasn't there really just > been one (admittedly major) one between 2.0 and 2.1? I don't think removing > the legacy classes in 2.3 counts as a pending BC-break; that's just > leftovers from the previous BC-break, isn't it?) I also don't really accept > that reorganising will noticeably ease maintenance. > > TL;DR: it's not great as it is, but it's hardly awful. If there were no > more changes until 3.0, I think I'd count my blessings rather than my > regrets :) > > Regards, > > Matt > > On 7 Jan 2013, at 12:06, Victor Berchet <vic...@suumit.com> 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. > > > -- > Matt Robinson > https://lazycat.org/ > > -- > -- > 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 > > > -- -- 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
