Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow passing initial seq, session_id and resume_url attributes to the shard, as well as retrieving them. #1662

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

davfsa
Copy link
Member

@davfsa davfsa commented Jul 18, 2023

  • Additionally export all impl classes to hikari namespace

@davfsa davfsa added the enhancement New feature or request label Jul 18, 2023
… to the shard, as well as retrieving them.

- Additionally export all impl classes to `hikari` namespace
@davfsa davfsa force-pushed the task/improve-external-api branch from bf57d3b to 34afeab Compare July 18, 2023 13:50

@property
@abc.abstractmethod
def seq(self) -> typing.Optional[int]:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

guaranteeing these properties (esp seq) for all shard impls would conflict with shard impls which aren't running the shard logic in the current process

Copy link
Member Author

@davfsa davfsa Aug 8, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are not going to make a "extremely generic" API, because then we might as well have an empty class, because each implementation could do whatever they want and decide how it works.

The idea for our API is to expose what external interface we expect our components to have.

If someone wants to make their own interface and implementation of what we do, they can always define and implement their own.

Once we hit a stable release, this API would not change until a major version is released.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are not going to make a "extremely generic" API

It isn't "extremely generic" right now either? These are just niche properties which most ppl don't need and I'm just trying to weigh the pros vs cons of enforcing them for every implementation (when the only one which needs to be a property here (.seq) just straight out cannot always be implemented properly) as opposed to just keeping them implementation detail which would also work for the intended use case.

If someone wants to make their own interface and implementation of what we do, they can always define and implement their own

Also how would they "make their own interface of what we do" for Shard, that just wouldn't be compatible with with Hikari's ecosystem all just because of a Shard's sequence number?

The idea for our API is to expose what external interface we expect our components to have.

what's the point of the ABCs then, sounds redundant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants