On 1/26/11 3:46 AM, Jeremy Mikola wrote:
We only recently started using events for our own purposes (instead of
creating listeners for core events), so forgive me if this is obvious,
but is there any use case for dispatching with notify() and still
wanting to examine the return value of the event object?

This is a nice side effect of removing *etReturnValue(). During a notify(), there should have no feedback from listeners (as only one would be able to do so).

If Event::getReturnValue() is removed, how would notifyUntil() return
the equivalent value?  Would that require altering listeners invoked via
notifyUntil() to return what would otherwise passed to
Event::setReturnValue() instead of a "true" value?

Yes, the listener would then have to set the event as processed and return the value.

I have started to change the code with the new rules to have a feeling for the new interface, and it is IMO much better and more intuitive.

Fabien

On Tue, Jan 25, 2011 at 5:07 PM, Fabien Potencier
<[email protected]
<mailto:[email protected]>> wrote:

    Hi all,

    Today, I've added interfaces for both the EventDispatcher and the
    Event classes. It made me think again about the method signatures.
    And I think we need to change them for the notifications methods.

    As of now, notify(), notifyUntil(), and filter() return the Event
    instance. This is a bit stupid as the event is one of the arguments
    of these methods (and chaining the methods has no use case).

    So, instead, I want to change the returned value as follows:

    notify(): no return value
    notifyUntil(): the value of getReturnValue()
    filter(): the filtered value

    With this change, the Event::getReturnValue() method can also be
    removed.

    What do you think?

    Fabien

    --
    Fabien Potencier
    Sensio CEO - symfony lead developer
    sensiolabs.com <http://sensiolabs.com> | symfony-project.org
    <http://symfony-project.org> | fabien.potencier.org
    <http://fabien.potencier.org>
    Tél: +33 1 40 99 80 80

    --
    If you want to report a vulnerability issue on symfony, please send
    it to security at symfony-project.com <http://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]
    <mailto:[email protected]>
    To unsubscribe from this group, send email to
    [email protected]
    <mailto:symfony-devs%[email protected]>
    For more options, visit this group at
    http://groups.google.com/group/symfony-devs?hl=en




--
jeremy mikola

--
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

Reply via email to