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 sfEventDispatcher implementation,
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!
- Marijn
[1]
http://www.google.nl/search?as_q=symfony+event+dispatcher&as_epq=&as_oq=&as_eq=&hl=nl&client=safari&rls=en&lr=&cr=&as_ft=i&as_filetype=&as_qdr=all&as_occt=any&as_dt=e&as_sitesearch=symfony.com+symfony-project.org+symfony-project.com&as_rights=&safe=images&btnG=Google+zoeken#q=symfony+event+dispatcher+-site:github.com+--components+-site:symfony.com+-site:symfony-project.org+-site:symfony-project.com&hl=nl&lr=&client=safari&tbo=1&rls=en&as_qdr=all&prmd=ivns&ei=4gqCTfPQC8aSOpXPvcMI&start=0&sa=N&fp=a6951e28e5d3f90d
[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
