You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a ticket to compare a couple refactor PRs.
Right now there is iffing and elsing on the spec version within apis/abstract.py.
Ideally this coupling should not exist, and should be contained within the Specification class / interface. @cziebuhr and I have been working through some ways to refactor a bit.
Comparison
@cziebuhr and I worked through a few ideas for doing code cleanup.
One approach was #726 which doesn't change the operation interface, and instead adds some convenience constructors to reduce coupling.
This approach goes to great lengths to avoid passing the entire spec to the operation, so it has a wider, but flatter interface. Any parts of the spec that aren't within the "operation" scope are passed in as separate arguments (e.g. app_security). This is how the Operation class was before I split it, so I just continued with the wide interface.
The other approach is #730 which passes the entire spec to the operation. This means that the operation class is more coupled to the spec (relies on parts outside of the operation scope). This is a skinnier, but deeper interface.
The implications are that it might be harder to use/test the operations classes on their own without having a full spec. It's also fewer lines of code, and more readable. Finally, it changes the operation interface, so is backwards incompatible (It's hard to know how 'public' this interface is, and what the impact of breaking compatibility would be).
What's next?
It would be nice to land some of this cleanup. I don't feel particularly attached to either one.
I think my preference would be to land #726 since it's ready and then continue to discuss/refine #730 since it can build on #726 (It's a bigger refactor with higher risk and reward).
Let me know what you all think.
The text was updated successfully, but these errors were encountered:
FYI I think #730 was closed automatically because the dev-2.0 branch was deleted.
Either way - @jmcs can you review #726 ? I think it's worth getting at least that bit of cleanup in.
Description
This is a ticket to compare a couple refactor PRs.
Right now there is iffing and elsing on the spec version within
apis/abstract.py
.Ideally this coupling should not exist, and should be contained within the
Specification
class / interface.@cziebuhr and I have been working through some ways to refactor a bit.
Comparison
@cziebuhr and I worked through a few ideas for doing code cleanup.
One approach was #726 which doesn't change the operation interface, and instead adds some convenience constructors to reduce coupling.
This approach goes to great lengths to avoid passing the entire spec to the operation, so it has a wider, but flatter interface. Any parts of the spec that aren't within the "operation" scope are passed in as separate arguments (e.g. app_security). This is how the Operation class was before I split it, so I just continued with the wide interface.
The other approach is #730 which passes the entire spec to the operation. This means that the operation class is more coupled to the spec (relies on parts outside of the operation scope). This is a skinnier, but deeper interface.
The implications are that it might be harder to use/test the
operations
classes on their own without having a full spec. It's also fewer lines of code, and more readable. Finally, it changes the operation interface, so is backwards incompatible (It's hard to know how 'public' this interface is, and what the impact of breaking compatibility would be).What's next?
It would be nice to land some of this cleanup. I don't feel particularly attached to either one.
I think my preference would be to land #726 since it's ready and then continue to discuss/refine #730 since it can build on #726 (It's a bigger refactor with higher risk and reward).
Let me know what you all think.
The text was updated successfully, but these errors were encountered: