Is property "EventArguments" 100% safe in all scenarios?

businessdad

I'm working on a plugin (thanks x00 for the tons of help) and I started using the Events mechanism. I saw that property EventArguments can be used to pass additional data to an event, but I also noticed something, in my opinion, odd: array EventArguments never gets cleaned up, and every event receives all the arguments eventually passed to previous ones.

For example:

$this->EventArgument['MyArgument'] = 123;
$this->FireEvent('FirstEvent');

The handler for FirstEvent will see MyArgument = 123. If, in another place, we do something like:

$this->EventArgument['MyOtherArgument'] = 'something new';
$this->FireEvent('SecondEvent');

The handler of SecondEvent will receive both MyArgument = 123 and MyOtherArgument= 'something new'. Of course, the second handler could simply ignore the arguments it's not expecting, but it's still quite "dirty" to have a single shared buffer for Event Arguments.

This is the first time I see this kind of behaviour, as I was used to the fact that Event Arguments live and die with the event itself; my main fear is that this mechanism it may lead to concurrency issues (but I admit I'm still a novice with Vanilla and I may be wrong).

x00

it is intended for stuff to be used within that controller, also it is often used where you re passing by object / reference. Meaning it you make changes to it affect the actual property.

the main reason for it, is sometimes a bit verbose to get the property from sender. Especial if you are using it over an over, it is deliberate that it is carried. You could always clear it yourself.

You could do something like this

$this->EventArgument['MyObject'] = $this->MyObjectParent->MyObject

or

$this->EventArgument['MyArray'] = &$this->MyArray

you would need to use &$Args in the even handler for the second, if you want to affect the actual array.

x00

Personally if you see it into the context that it is used, and consider that there is a lot of shared data anyway.

However you are coming from an erlang background you would say I prefer to be in a room on my own, nobody visits, but people send me messages, and I act on them. I have quite a lot of sympathy for that way of doing things.

However OOP being what there is so long as you are in context, then there is no reason not to share data.

businessdad

x00 said:
However you are coming from an erlang background you would say I prefer to be in a room on my own, nobody visits, but people send me messages, and I act on them. I have quite a lot of sympathy for that way of doing things.

I don't actually know erlang, but every language/environment I've used encouraged a fairly high degree of isolation, and I haven't seen a "free-for-all shared buffer" for years now. I agree it comes handy, but I'm wondering if it wouldn't lend itself to abuse.
On the other hand, we all know that "if one wants to abuse of a system, he'll find a way", that's why I think I may be worrying for nothing.

x00

$EventArguments are public, but is a property of that class. It is not different from public properties of the sender, except you can use it for anything.

it is not shared in the sense that two pluggable classes don't share the same event arguments

x00

remember that events are just a window into that context at that point. EventArguments are just a convenience property (which is already public).