Yeah normally packages don't include test abstractions
Hmm can't say I'm 100% convinced, but i'll take your words for it and keep it in mind for the next major version.
[Unrelated Note Alert] Generally speaking for the next major version, as of now i only plan on a few cleanups which might result in some API breakages but won't change the shape of the library much.
Stuff like cleaning up the
DefaultDiscordClient with a
ClientTransport, removing those abstractions like you said, changing Snowflakes' underlying value to be of UInt64 type, are the most major changes. That release won't be coming too soon as i want to first support Voice as well as provide some kind of convenient Slash Command APIs like swift-arguments-parser or possibly with macros. The Slash Command stuff can be a game changer and be a distinguishing factor when compared to any libraries of any other languages.
That's interesting. Why don't we inject the cache into the client? Also what is in the shared cache between the clients?
The shared cache is acquired here.
What does it do? If
DiscordClient.configuration.cachingBehavior allows caching a request, the
ClientCache will be used as the store. Note that this behavior (response-caching) is disabled by default.
An async call is inevitable if the cache is needed, unless the cache is moved to locking mechanisms.
Maybe i could somehow provide a default init that does not do caching and can identify that so it can dodge the acquire-cache call. Currently the
DefaultDiscordClient inits don't try to identify if a client-cache isn't needed, so they try to acquire a cache anyway, thus the async call.
you really don't want to return
AsyncStream here but rather implement your own
AsyncSequence which you can back by an
I'll keep that in mind. I need to do some more digging until i can say i'm confident about my knowledge about async sequences.
Also you probably only want to let this
events property only be called once otherwise you have to think about what happens if there are multiple consumers.
The library is built around having the possibility for having multiple "listeners" of gateway events. Removing that possibility can result in a decent amount of inconvenience for users from what i can think right now, because currently other types such as
DiscordCache also need to somehow receive all the events separately so they can perform their own work on them.
How it all works right now is that when you do 'bot.makeEventsStream()', the
GatewayManager will create a new async stream, store the new continuation in the array of continuations, return the async stream, then yield new values as they come.