Event Cause Refactor

[gabizou]

Currently, the first iteration of Cause usage was useful for a variety of things, however, we've come to a point where we need to separate what is the "cause" of an event versus the "context" of an event.

One of the things that would take place would be the following:

Event gains a new getter for the direct cause of an event, possibly will recycle Cause.

Event also gains a new getter for the context such as EventContext, of which named objects are included, a method simply named as Event#getContext() or possibly getEventContext.

Of course, this will not take place until likely 1.9 as a majority of breaking changes are taking place there.

[gabizou]

Prodding @SpongePowered/developers for input

[Aaron1011]

@gabizou: Will EventContext take on all of the other functions of Cause?

[bloodmc]

We shouldn't require every cause to have a name due to performance reasons so whatever we can do to fix this would be good.

[Lunaphied]

@gabizou What are you considering part of the event's context rather than its cause?

[gabizou]

Will EventContext take on all of the other functions of Cause?

EventContext is going to be implied that it will be contextual information, mostly by String keys (basically take Cause and rename it EventContext, it'll be easier to manage since it will be utilizing strictly NamedCauses over the current mapping used).

Cause itself will likely need to be rethought, but the current idea is that Cause will only contain the direct cause of the event and eliminate the needs for naming.

We shouldn't require every cause to have a name due to performance reasons so whatever we can do to fix this would be good.

The root performance reason is that you're chaining causes continuously, which of course is going to end up having some cost of either generating new strings, or validating that the objects are distinct.

@gabizou What are you considering part of the event's context rather than its cause?

Read above.

[TheRaspPie]

@gabizou So basically, do you take NamedCause.SOURCE as a cause and all the other ones as context? May a context be empty then and a cause not?

[gabizou]

@TheRaspPie They'd be two separate objects entirely. The Cause of an event would only be a single object, if not a collection of directly directly causing cause objects to remain, as such they are considered the "Source" of an event. Contexts would reside within the related event, so DamageEntityEvent.ATTACKER, etc.

[DarkArc]

One thing which troubles me, is many times I've wanted to differentiate between a plugin and something natural. Like an added item drop, and a vanilla item drop. I don't like how in the current system, a cause can be a plugin. That's an implementation detail IMO, and as such it should not be part of the cause.

Instead, I think we need some concept of "markers." I'm not sure what that should be, or if it should just be part of the context. But I think there should be a separation between game play context, and implementation context, and furthermore causes should never be based on an implementation detail, but instead what is observable from the players perspective.

[Zidane]

@DarkArc

I don't fully agree on the premise that the plugin container being in the cause IS the marker. Only when an API method triggers the event will the plugin container end up in the cause. Otherwise, that is a fault on Sponge's behalf. The API contract of these methods that trigger events should always take a PluginContainer and, therefore, it can be reasonably expected for a plugin dev to check a cause FOR a PluginContainer and then know right then if its natural or not. That fact alone removes the implementation detail aspect.

On a similar note, why does it matter? I mean, the point of Cause/Context is for you to simply query for what you want. Sounds like you don't want to perform logic on plugin-triggered events, which is fine, but otherwise plugin devs should never care. Query for what you want and go.