On Mar 17, 3:43 pm, Jonathan Wage <[email protected]> wrote: > Hi, > > Thanks for taking the time to type your opinions.
The pleasure was all mine Jon :-) > > On Thu, Mar 17, 2011 at 9:28 AM, Marijn <[email protected]>wrote: > > > > > > > Hi everybody, > > > After reading the logs of the IRC meeting about dropping the Symfony event > > dispatcher in favor of a fork of the Doctrine version I felt compelled to > > vote against in the related pull request. > > As some people have told me it would have been better to raise my concerns > > here in the developers mailing list if I wish to change peoples minds. > > On a side note, I wanted to post this earlier but unfortunately I couldn't > > because of my final exams. Given the current status of this I'll post this > > right away instead of a proper proofread a day later, apologies for spelling > > errors and broken sentences: please bare with me. > > > First and foremost I would like to say that I'm not against the change per > > se, it's merely the timing. Personally I have been using symfony since > > version 1.1 was just in alpha. In that time I have become very familiar with > > the event dispatcher as it is a great way to extend core behaviors in > > symfony 1.x and a great tool to create less coupled (proprietary) > > libraries. > > Since it's initial launch a lot of articles and talks have been showing > > examples how to decouple code by using our sfEventDispatcherimplementation, > > although it's hard to asses the exact size searching for it > > online and removing al well known symfony websites still results in some > > very useful articles and presentations [1]. > > > The mantra behind Symfony to provide a low level quality API that serves > > the developer with best practices and reduces the amount of concepts to a > > minimum is great! > > That was why I was very enthusiastic to see that Bernhard started working > > on an implementation of the Doctrine event manager. It would remove the need > > to learn two event implementation for a lot of developers. Although I'm much > > more familiar with the original sfEventDispatcher and it's name spaced > > successor in Symfony I immediately understood this would benefit me as a > > developer in the long term and hence was not reluctant of this change. > > Perhaps I should add that I've been using Doctrine 2 in quite a few > > production projects for the past 18 months (with either symfony or in > > combination with SabreAMF) so I'm definitely familiar with it's event > > system. > > Even better contra argumentation: I often subclassed sfEvent to create a > > more rigid contract between my notifiers and my listeners, I never really > > liked the ArrayAccess approach. > > > Though when I found out that this implementation would be a custom fork and > > not an (extended) version of the existing Doctrine event manager I was a bit > > confused. > > What is the benefit of moving to this new implementation? > > We have a lot of users out there that just moved into the 1.1+ versions of > > symfony where they have learned to master and benefit from event driven > > programming and now we're going to ask them to learn yet another > > implementation on top of all these new concepts introduced in Symfony. > > Besides that, there are a lot of Bundles (194 at the moment on > > symfony2bundles.org) and libraries (e.g. Behat though I'm unaware of his > > opinion on the matter) that also use our implementation. These will now all > > have to change their codebase significantly for what appears to me to be a > > minor benefit. > > > *The big arguments in favor are more rigid contracts.* > > We can do that right now by sub-classing our Event classes. This would not > > effect current code base of other people nor will it create a need for new > > documentation. Better even, we still have a very lightweight and simple way > > to create event driven programs without the need to create subclasses per > > se. > > > *The other big benefit: readability.* > > Our original sfEventDispatcher implementation does not ask us to name our > > listeners different than our event, that is something we do ourselves. > > Personally I've always hated it when an event listener was named > > changeCulture(sfEvent > > $event). > > So I just create a semantic method name onUserChangeCulture(sfEvent > > $event) wich will determine if all parameters where sent along and do > > something like changeCulture($culture = $event->getParameter('culture')). > > This is really up to us and although I agree with the argument that it is > > *nice* to have the library enforce us it doesn't mean we can't write > > readable code without it. > > > *The argument that returning a value in a listener is bad.* > > Bernhard suggested that returning a value in a listener is bad and that the > > use of setProcessed is confusing. > > It seems to me that this is a re-incarnation of the rigid contract argument > > and that it can be wiped of the table by subclassing current Event classes > > because, as he put it himself the Event instance can than decide for > > itself when it is processed. > > Again, I don't see why we need a new event manager implementation for this. > > Besides that this is what it was like before, by calling > > $event->setReturnValue(...) with a for example a response. > > To me actually returning a value in a listener is a lot more transparent > > than calling setReturnValue so I think the API has improved there. > > But perhaps I misunderstood Bernhard here... If so, please correct me! > > > *The filtering of values and stopping execution: what if you want to > > filter a value but still stop propagation?* > > To me this again is a merely a question of semantics. If you're filtering > > and want to stop the execution than it is not a filter. > > If someone could prove me wrong on this please do but as far as I know and > > read it in the documentation you as a notifier are aware that more than then > > one listener might filter your value and the same goes for filtering > > listeners, they know they might not be the only one. > > Besides, to me it seems that if the author of an extension point choose > > filter there is probably a good reason for it. If we stop execution of other > > listeners unexpected behavior might be the result. > > > So it all comes down to this question, are these benefits significant > > enough to justify a complete different event implementation that will not > > reduce the amount of concepts for our developers (i.e. end users of the > > code). > > My answer is no! We must not forget that we are all very much ahead of the > > average user in the symfony community. > > My developer friends that had not played around with Symfony where > > overwhelmed by the amount of new concepts during SymfonyLive. > > Please remember that having a few things around that people know will help > > them grasp the meaning of the other things introduced. > > Please remember that currently working code with the original > > sfEventDispatcher can be made compatible with a single use > > Symfony\Components\EventDispatcher\EventDispatcher as sfEventDispatcher > > statement > > at the beginning of the source. > > This change would have been rather easy to sell to our community if it > > would mean events management of Doctrine and Symfony would be the same. > > The way we are headed it's not and to me that entails that we cannot argue > > this change is favorable enough for our users. > > > Last but not least: I kindly ask you to really take the time and think of > > the arguments that were raised in this post and on the github pull request > > [2] and ask yourself this question and dare to be critical to yourself and > > your peers: > > * > > * > > > *Do we really make better programs with this implementation?* > > > I humbly salute you, thanks to all you great, inspiring developers out > > there! > > 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! > 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... > > - Jon > > > > > > > > > - Marijn > > > [1] > >http://www.google.nl/search?as_q=symfony+event+dispatcher&as_epq=&as_... > > > [2]https://github.com/symfony/symfony/pull/221/ > > > -- > > 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 > > -- > Connect with me on *http://twitter.com/jwage*<http://twitter.com/jwage> > andhttp://about.me/jwageto keep in touch. -- 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
