Proposal: Non overriding events

[ShayBox]

Describe your proposal

An event option to prevent an event from overriding the built-in core event if provided.

Use-Cases for your proposal

You could have both the core event functional, and a personal event without one being overridden.

Expected and actual behavior

An event with the option override: false will not override a core event.

Further details

By default all events's override option would default to true, to keep the current functionality the same and not break things, and allow users to create events that do not override core events, Ex.
The core message event working
A personal message event with override: false, doing something completely different than the core event.

This keeps the core events in-framework, keeps them up to date with the framework, rather than having to require users to copy all the code from events they need access to into their events then keep that code up to date, when they never modify the code in the first place.

Another possible configuration would be, Ex.
A message event with override: true (default) that overrides the core event, that you would copy and modify the core event's code into, to modify the functionality,
Then allow you to add a second event with override: false that has an entirely different use, doesn't contain the core event code or any variant, and both of them function.

• This (as described) doesn't include any breaking changes.

[bdistin]

You can already have non-overriding events, so long as the name is different from core. Event#name is by default the name of the file, Event#event is by default the Event#name. But you can name the file differently, and set Event#event back to the intended event. Events are stored in the EventStore by name, so that's why events with the same name overwrite each other.

The only way to make this proposal really work the way I think you want it to work would be by renaming the core pieces away from their base event name, and setting their event option back to the event name they are supposed to handle, which would be breaking for all those who have transferred events to overwrite core functionality.

I am not opposed to that breaking change, but if we do that, we would need a predictable naming scheme. Do you have any suggestions?

[kyranet]

Maybe we should make this a little more clear in the guides, as they have no mention of it.

[kyranet]

With #475 we're starting to prefix core events with core to prevent any naming conflict, so you can have per-say a guildCreate event handler separate of the built-in one without naming it differently to prevent the conflict. The changes will be applied to all events with or after the settings (#425).

This is a breaking change, however, as if the override was intentional, they'll need to rename and set the constructor to point to the right event.

[ShayBox]

Going to close this as it's been merged