[Nerixyz]

In Chatterino, "controller" is technically a euphemism for "singleton". One practical difference is that controllers have subdirectories (e.g. controllers/hotkeys) as opposed to singletons.
In #6436, I want to add some other classes related to emotes. Since they're semantically related, they should also be physically related by being in the same directory. Hence, this PR turns Emotes into an EmoteController. The controller has the following differences:

• Removed IEmotes in favor of a virtual initialize() that subclasses can reimplement. This way, the accessors don't need to be virtual anymore.
• Removed get prefix of trivial accessors.
• Used unique_ptr for all members to avoid including too many files (e.g. TwitchEmotes.hpp).

[pajlada]

In Chatterino, "controller" is technically a euphemism for "singleton". One practical difference is that controllers have subdirectories (e.g. controllers/hotkeys) as opposed to singletons.

In Chatterino, singletons are something that are created & accessed statically, we just haven't renamed/moved classes out of that directory. Controllers are meant as Application-owned once-constructed "backends" for data.

Removed IEmotes in favor of a virtual initialize() that subclasses can reimplement. This way, the accessors don't need to be virtual anymore.

This removes the ability for us to mock the members of the emote controller (I know we haven't taken advantage of this). Do you foresee mocking of Emojis/TwitchEmotes or EmoteController to not be necessary?

When you say "...that subclasses can reimplement", what subclasses do you have in mind?

[Nerixyz]

This removes the ability for us to mock the members of the emote controller (I know we haven't taken advantage of this). Do you foresee mocking of Emojis/TwitchEmotes or EmoteController to not be necessary?

I don't think we need to mock the members. The closest would be TwitchEmotes if it were to load some emotes over the network. However, that would happen in some initialization method. We can omit this potential call with the current design.

When you say "...that subclasses can reimplement", what subclasses do you have in mind?

The only subclass is the mock that omits initialization.