One of the the pros for these Events classes is that you have auto-completion for which events are available. That's really the only purpose these classes serve, and imo it is a good thing.
However, there is a chance for conflicts, but I think this is more a documentation issue; we probably have to create a naming convention for events to make sure people do not create conflicting names. Kind regards, Johannes On Mon, May 2, 2011 at 9:27 PM, Jordi Boggiano <[email protected]> wrote: > Which honestly is a stupid idea. It works in a very constrained use > case like doctrine, but otherwise it basically means that method names > have to be unique for every event, across the entire project, it means > we have to namespace method names.. > > What a great step forward this was. > > Flash had the same way in early versions with ActionScript 1, you'd > have to use: on (foo) { some code } for your event handlers. Now in > AS3, just like in JS, you can attach listeners with a callback to any > event dispatcher, method names don't matter and every dispatcher can > have any event name that can clash. Just like we had before actually. > Of course we don't have that many events so having one central > dispatcher with slightly longer (namespaced) event names makes sense > for us to keep a low footprint, but global namespace for method names, > really? > > Why did we change again? > > Cheers > > On Mon, May 2, 2011 at 9:20 PM, Kris Wallsmith <[email protected]> > wrote: > > I liked that too, but the event name has to be a valid method name now. > > Kris > > > > On Monday, May 2, 2011 at 12:19 PM, Jordi Boggiano wrote: > > > > On Mon, May 2, 2011 at 9:09 PM, Kris Wallsmith <[email protected] > > > > wrote: > > > > I think it is misleading to the user to encourage the use of class > constants > > as event names. An event name is a simple string in a global namespace > while > > a class constant includes a namespace and class name. I am concerned that > > users will create disparate class constants with the same value, leading > to > > a collision. For example, if Foo\Bar::preExecute and Bar\Foo::preExecute > are > > both equal to 'preExecute' they will both trigger the same listeners when > > dispatched, which will probably lead to unexpected results and some > > unnecessary WTFs. > > The best solution I can think of is to stop using class constants and > just > > use simple strings instead. This will make it clear to the user that they > > are dealing with a simple string in a global namespace. > > $dispatcher->dispatch('preSomethingExecute') > > What do you think? > > > > I think I liked how it was namespaced before, core.request, > > core.response, it looks like service names etc. Now it looks like IE's > > onfoo JS events, except with a camelCased spin on them. > > > > Cheers > > > > -- > > Jordi Boggiano > > @seldaek :: http://seld.be/ > > > > -- > > 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 > > > > > > -- > Jordi Boggiano > @seldaek :: http://seld.be/ > > -- > 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
