opened
Deamon5550
username_0
Any event now has two objects attached to it, a cause and a context. The cause contains
an ordered stack of objects which are the direct cause of the event. The context contains
objects that are tangentially related to the event being thrown that the thrower of the
event thinks would be useful for proper handling of the event.

In the cause only the order matters, in the context only the names matter. A cause has
no names and a context has no ordering.

Previous the values of these two objects were both present in the cause which can cause
some confusion and misaction. Forexample you could attach a player to an event to which
there are only slightly related to but if no other player is in the cause before them then
cause.first(Player.class) will still return that player even though there are by no means
the cause of the event.

![Dont panic](https://i.imgflip.com/1bc26q.jpg)
Split Cause and Context
issue
created
Zidane
username_1
@username_0 

If we stick to our guns with CauseStacks, should we toss out wrapper causes entirely?
comment
created
Deamon5550
username_0
@username_1 Yeah the purpose behind the wrapper causes was to attach for example with the `EntitySpawnCause` you and the entity that causes the spawn and the spawn type. Under the new system though the spawn type would be part of the context and the entity would simply go in the cause stack.
comment
created
Zidane
username_1
@username_0 

Thinking further, are we going to stop duplicate classes existing in a Cause stack? So, for example, two Players would never exist in a Cause.

If not, without naming how would a developer ever know?
comment
created
JBYoshi
username_2
What's the status on this?
comment
created
Deamon5550
username_0
I consider this api change in pretty good shape and the implementation of it compiles now. While there is still testing on the implementation to be done this PR is finished so now is the time for more comments.
comment
created
varrix
username_3
Just caught up with SOS that broke down how this works on the usage end, really great work everyone! :fireworks:
comment
created
Faithcaio
username_4
Any reason why there is no method to get all ContextKeys present in an EventContext?
comment
created
Deamon5550
username_0
@username_4 [there is](https://github.com/SpongePowered/SpongeAPI/pull/1370/files#diff-fbf61a811a6be0f7c3ed1b2b3fc7d79aR122)
comment
created
TheRaspPie
username_5
Could you make EventContext implement the read-only part of the java.util.Map interface and Cause the Collection interface?
It would be so much easier to work with APIs that work with generic interfaces.
comment
created
Deamon5550
username_0
@username_5 That doesn't work actually as the get method has to return an `Optional` and I don't want to change it. I will add more methods that emulate those in the `Map` interface as well as rename the `keys` method to `keySet` for consistency.
comment
created
liach
username_6
finally!
comment