Discussion about differentiating between Socket, Http and possibly Cache entities

Summary

There has been some discussion before about inconsistencies in entities received by either the WebSocket, HTTP requests or from the cache. This issue has come up in several issues before (#583, #582, #472). Other issues that are partially related would be (#435, #571). Opening this issue for centralized further discussion.

Details

I personally think it would be best to create abstract classes for entities that contain fields that are always available. For Socket and HTTP we’d implement these abstract classes with the additional fields these channels provide. We could also provide a separate Cache entity for everything that gets cached, but I’m not 100% sure whether that’s a good idea (yet).

Some pseudocode on what I’d assume it to look like

DiscordSocketGuild guild = e.Guild; // A guild received by the websocket, e.g. in an event handler.
DiscordHttpGuild guild2 = await client.GetGuildAsync(379378609942560770); // A guild received from HTTP
BaseDiscordGuild guild3 = guild; // DiscordSocketGuild implements BaseDiscordGuild so we can assign it to that type
guild3 = guild2; // So can we for the HTTP guild

After assigning our guild to BaseDiscordGuild, we’d assure that all fields on that type are available.

Of course, my word is not final. Please discuss on other viable solutions, or improve on what I proposed. (yes, I’m technically a main maintainer but for this project it’s more important to do what the community wishes)

[VelvetToroyashi]

What I mean is more akin to: IEntityWhatever as the abstract base for anything that is an EntityWhatever (say, guild), and then you have GatewayEntityWhatever and RestEntityWhatever, the 2 of which the users don’t know about, they only deal with the IEntityWhatever type. This complicates dealing with differences between gateway and REST a little, but avoids the “oh no as ConcreteType1 didn’t work because it’s as ConcreteType2 ur lib is shit fix nao”

Just chiming in regarding this; while I do agree that abstraction is a double-sided coin with lots of pros and cons, when it comes to responsibility and accountability for abstraction, I feel the liability of dealing with egregious issues that simply state “lib no work plz fix” is not ours; if we provide abstractions, it’s up to the end user to be competent enough to realize what an abstraction even is, especially in the case of realizing something is an interface and trying to cast to a concrete type, but that’s just my two cents.

Look forward to seeing where this decision goes, as I’ve whined about abstraction before, and currently resorting to my own, but even the most basic interfaces would be much appreciated. ❤️

[Emzi0767]

One thing I don’t think should happen, because it was a mistake dnet made, was allowing direct access to underlying type. Guarantees should be made about what the object contains and can do, but not about what it is.