Hi Chrishtophe, On Mar 17, 2011, at 4:13 PM, Christophe COEVOET wrote:
> Le 17/03/2011 15:53, Marijn a écrit : >> On Mar 17, 3:43 pm, Jonathan Wage<[email protected]> wrote: >>> >>> I really disagree. I think in the long run the benefits outweigh any short >>> term annoyance right now. Keep in mind Symfony2 is still alpha so I don't >>> think it is unreasonable to change this. >> The arguments I have listed never mentioned that the change is >> unreasonable, I'm well aware of the fact that the code is still in >> alpha stage. >> >> My primary concern is the fact that by changing this our community >> will have to learn another implementation. Like I said I'm aware of >> the benefits but I argue those benefits can be realized with the >> current implementation. >> Doing so would save us the resources that now will be used to write >> new documentation and change a lot of bundles. >> Don't forget the lack of examples, articles, blog posts, forums and >> questions on sites like stack overflow. This will slow down adoption >> (maybe marginal but it will). >> >> My argument is simply that we can realize the benefits from this >> change without a different implementation which will benefit the time >> and resources we have available! >> > Keeping the implementation just because it is the same than the symfony 1 one > is not a good argument. Symfony 2 is not backward compatible with symfony 1. > A component relying on a sf1 component can either be ported to use the new > implementation, either keep the sf1 component. I feel like I'm repeating the same arguments over and over again: the same benefits can be realized without changing the implementation! This will benefit us as developers because we have more time to polish other parts of the framework. Like I said, changing it to _use_ the doctrine version with have been fine as well, less code to maintain for devs and less concepts for the users. In my opinion there is no argument that justifies a change: it all can be done with our current implementation. > Thus, keeping the implementation now will forbid to change it for the whole > Symfony 2 lifecycle as backward compatibility will be needed this time. So it > is the only chance to change the implementation. I'm well aware of that and that's why I keep proposing to change it to _utilize_ the _exact_ doctrine implementation or keep it as is and subclass our current event classes to provide those rigid contracts... >>> It is hard to see now the effect it will have, but I think it will have a >>> long lasting effect on the quality of the code produced due to the rigidness >>> of the OO semantics the developer must abide by now. This is the direction >>> PHP, Symfony2, Doctrine2, etc. are going. More rigid and explicitly defined >>> semantics and less magic lead to less WTFs and unexpected edge cases. >> This seems kind of broad spectrum argumentation. I agree with you that >> this is _the_ direction but I think it is possible today without >> switching from an event dispatcher to an event manager.. > > > -- > Christophe | Stof > > -- > 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 -- 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
