-
Notifications
You must be signed in to change notification settings - Fork 24
Update traits to allow for dynamically discoverable implementations #395
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
Conversation
| get_payload_member, | ||
| ) | ||
| from .traits import EVENT_HEADER_TRAIT | ||
| from smithy_core.traits import EventHeaderTrait |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just for my understanding, is the EventHeaderTrait ever used outside of an Event Stream implementation? Is this just being ported back to consolidate all the traits together or is there another theoretical library we'd use this in?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is only ever used by event streams, yes. But it could be used if we had an alternative event stream format or something like that. I've kept all the traits in core because so far we're only using traits from Smithy's default set of traits. But we could conceivably split them up too.
This updates traits to use a dynamic registry to allow concrete implementations to be automatically discovered and created when constructing schemas.
e48e902 to
a33dcb9
Compare
|
had to rebase |
| comfortable to use, providing better typed accessors to data or even relevant | ||
| utility functions. | ||
|
|
||
| Both kinds of traits implement an inherent `Protocol` - they both have the `id` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
| def expect_trait(self, t: ShapeID) -> "Trait | DynamicTrait": ... | ||
|
|
||
| def expect_trait(self, t: "type[Trait] | ShapeID") -> "Trait | DynamicTrait": | ||
| """Get a trait based on it's ShapeID or class. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| """Get a trait based on it's ShapeID or class. | |
| """Get a trait based on its ShapeID or class. |
This updates the design for traits from being simple bags of loosely typed data. Now traits may instead have concrete implementations that are discoverable dynamically simply by implementing the relevant subclass.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.