Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Refactoring message event hierarchy; other tidyups. (#227)
* Refactoring message event hierarchy; other tidyups.
I will outline the other tidyups before the main change, as they are only
brief.
- PRIVATE* intents are now named DM* intents to match terminology across
the rest of the library.
- hikari.utilities.mappings is renamed to hikari.utilities.collections.
- IDTable from hikari.utilities.cache is moved to hikari.utilities.collections,
has been refactored and fully tested, and altered to be slightly more
efficient.
- IDTable is now named SnowflakeSet.
Cache mappings have been renamed to be a little clearer as to what
they really are doing.
- DMChannelMRUMutableMapping is now named DMChannelCacheMapping.
- MappedCollection is now named ExtendedMutableMapping.
- DictionaryCollection is now named FreezableDict.
- MRIMutableMapping is now named TimedCacheMap.
- CMRIMutableMapping is now named LimitedCapacityCacheMap.
Message hierarchy changes
-------------------------
Due to the fundamental differences between create/update/delete events and
information they contain for messages, I have concluded that the complexity
created by having these staggered classes is not overly helpful in writing
robust error-safe code. It is definitely not worth the extra overhead, as
there is almost no cases where this is overly useful where you could use
this in such a way that using two event listeners would not be more
terse and idiomatic.
Therefore, GuildMessageEvent and DMMessageEvent no longer exist. The new
hierarchy is as follows instead:
```
Event
|
|-- ShardEvent
' |
' |-- MessageEvent
' |
' |-- MessageCreateEvent
| |
| |-- GuildMessageCreateEvent
| '-- DMMessageCreateEvent
|
|-- MessageUpdateEvent
| |-- GuildMessageUpdateEvent
| '-- DMMessageUpdateEvent
|
'-- MessageDeleteEvent
|-- GuildMessageDeleteEvent
'-- DMMessageDeleteEvent
```
** Bulk deletion events **
Bulk deletion events have been merged with deletion events.
The reason for doing this is because Discord already provides
little to no useful information for singular message deletions
other than the message id, the guild id, and the channel id.
This means that no stateless information about what was in the
message nor who made it or who even deleted it originally
can be discovered without polling message history before the
event can occur (which is basically impossible), or by
maintaining a long-lived message cache (which is not yet
supported fully on this API). This would also need heavy audit
log polling to be somewhat effective.
This is pretty much a limitation of how Discord operates,
unfortunately.
This means the only reasonable use case for this event currently
is for tracking any kind of message deletion. The bulk delete
event shares practically the same shape as the singular deletion
event, and anyone listening on deletion events for handling of
things like pagination will therefore almost always want to
listen to both events.
The interface for this event model is now to provide three
attributes to handle detecting which messages were deleted:
- `message_ids`: will be a `SnowflakeSet` of each ID that
was deleted. In singular message deletion cases, this
will always have a single item.
- `message_id`: to match with the `MessageEvent` interface,
and to provide a shorthand for cases where people really
do want to handle only a singular message deletion, rather
than an operation where you would just iterate across
the SnowflakeSet. For bulk deletions this will return the
first deleted message (implementation detail makes this
the smallest magnitude snowflake that is sent).
- `is_bulk`: true if a bulk deletion, false if not.
Additionally, since it is undocumented, bulk deletions in DMs
will now result in a NotImplementedError should they occur
(which unless Discord break their API contract, should not
happen).
It is worth noting message deletion events no longer have a
`message` attribute either, as this was pretty much a complete
waste of space given nothing could be in it in the first place
other than the id, channel_id and guild_id.
** Message Update Events **
Now that we have ditched the previous structure for messages,
we can make several attributes such as `author` and `guild_id`
simpler on the PartialMessage model that only the
MessageUpdateEvent uses. You now only have to `None`-check
the `guild_id`, and the `author` should always be present.
** Message Create Events **
This interface is mostly the same, other than having some
property definitions refactored.
* Fixing message update events to cater for optional author.
* Added handling for members in message edits being optional.
* Fix annotations for guild message creates with author property.- Loading branch information