But could you provide some use cases? The only one that came to my mind after posting were behaviors. There was a feature request, that they should have the possibility to extend the component they are attached to with new events. With the new event system, they could do this easily by calling:

$this->owner->trigger();

If trigger was protected, they had to raise their own event:

$this->trigger();

Now, if you want to hide the fact, that the event comes from an behavior instead of from the host component, the base Behavior class could easily override Component's trigger() implementation:

ben - behaviors are the main use case, keep in mind that behaviors cannot override methods that exist in the attached class so I don't think your example would work, i also posted another specific use case earlier in the thread: http://www.yiiframew...post__p__142981

Well, you can't change what happens when the behavior's host calls trigger(), but you can override Behavior's trigger() method which it inherited from Component. This way, the event dispatching logic could be modified for all events originating from Behaviors (setting sender to $this->owner instead of to $this).

I needed a second look to understand your example, so just for reference:

- You have an article class
- You attach different behaviors to the article (your states)
- One of the states defines a read-event
- You're trying to register to this event
- Because of the current event system, you need to ensure the article is currently in the correct state before registering
- Ideally, you don't want to bother with article's state, you just want to configure "if it gets read, call this method". You shouldn't have to deal with the fact that it can only be read once it is published.

Now, I don't know how qiang implemented the new event system. Let's assume that there's no way to check if a certain event has been declared. Instead,

simply creates a new event for article. Let's also assume that only your attached state triggers the event (can I make this assumption? If yes, trigger() can be protected). The trigger() implementation could look like this:

That won't work if you have properties with the same name as the event, i think qiang's implementation is absolutely fine. One thing though, the second parameter to trigger() should be optional, it should just raise a new default event with the object as the sender if it isn't specified

Shouldn't really have those circumstances off the top of my head, another option tho is: