-
Notifications
You must be signed in to change notification settings - Fork 219
refactor: clean-up WorkflowReconcileResult and Condition #1388
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
Merged
Merged
Changes from all commits
Commits
Show all changes
7 commits
Select commit
Hold shift + click to select a range
6035b85
fix: grammar
metacosm 62994be
refactor: clean up WorkflowReconcileResult
metacosm 2918973
refactor: make it easier to create Conditions
metacosm c5cead4
fix: properly implement Condition
metacosm 31eaaf2
refactor: simplify handling of filters
metacosm c7689f1
fix: do not use Optional in Condition, fix generics
metacosm 6ea3dde
docs: add javadoc
metacosm File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
14 changes: 0 additions & 14 deletions
14
...ore/src/main/java/io/javaoperatorsdk/operator/api/reconciler/dependent/VoidCondition.java
This file was deleted.
Oops, something went wrong.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
TBH before it was more expressive before, kinda describing that what is there it is a special value - so presumably handled specially subsequently. Taking a look on this is little confusing? maybe document it?
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.
I don't think we lost any expressiveness with this change: the default is the non-instantiable interface so it fulfils the same role as a default value (i.e. we can effectively check that the provided value is not the default one) without the need to create an additional 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.
Hmm, not sure, I mean VoidCondition has explicitly in it's name that it is about not having a condition. Byt fine by me also this way.
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.
The problem with
VoidCondition
is that it is still an implementation, meaning that if we somehow forget to check for it in the code that processes the annotation then you get a valid condition which is not what you want.Condition
itself cannot be instantiated so if we don't process it, this will lead to a quick exception making it easier to figure out what is wrong as opposed to tracking down why some events are processed when they should not be because we forgot to check forVoidCondition
somewhere.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.
Making
VoidCondition
abstract would help with that, since it would instantly fail. Also now it throws always an exception, so it will instantly recognized in any test something is wrong.But again I'm fine with both, I like that there are no more dedicated classes, just needs to be documented that this is the intention putting the interface there as default, that is a good enough alternative for me :)