-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
✨ Use generics for predicates #2265
✨ Use generics for predicates #2265
Conversation
Welcome @nikola-jokic! |
Hi @nikola-jokic. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: nikola-jokic The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Hey @alvaroaleman 👋 I hope this is what you meant by using generics |
pkg/predicate/predicate.go
Outdated
return Funcs{ | ||
CreateFunc: func(e event.CreateEvent) bool { | ||
return filter(e.Object) | ||
v := e.Object.(T) |
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.
We still have the type assertion here and its possible to misuse this by constructing a predicate for the wrong type. What I'd want is the whole chain of source/predicate/handler using generics. I'll update the issue to clarify that
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.
On 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.
Update
The only thing I'm having trouble with is builder
Right now, builder can watch multiple resources and I can't really instantiate many watches with different type parameters using generics without providing a top level function and potentially changing the interface of the Watch
method
I'm looking into ways of doing it, so the change is as minimal as possible
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 looked into this some time ago. Golang doesn't support generic methods, which is why we can not keep assembling everything in the controller.Watch but instead have to provide predicate+handler in a constructor to the source
ctrl controller.Controller | ||
ctrlOptions controller.Options | ||
name string | ||
} | ||
|
||
func newObjectPredicate[T client.ObjectConstraint](p predicate.Predicate[T]) predicate.Predicate[client.Object] { |
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 heavily work in progress, but I wanted to push changes to make sure this approach is okay
Since controller is able to watch on multiple resources, the only way I could think of (since we can't use generic methods) is to create a generic function that will convert this generic type to a client.Object
That way, the complexity is internal, and we use client.Object
interface internally. The caller still can leverage generics to use those types
The only thing is that the project needs to be go version 1.20, because they added interfaces to be comparable in that version
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 does not work now, there are many tests where I'd have to provide types and similar
The controller watch is also something that needs to be changed or provided another method like controller.WatchType(WithWatch()
that can be a generic function returning wrapped objects
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.
Since many types can handle multiple types, wrapping them in interfaces was the only thing that I could think of to provide a nice API... Some types can be improved, but the only thing I wanted to ask is, is there a different approach I should take?
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 the issue I was referring to in #2265 (comment). We have to change how this works in order to accomodate generics. The source needs to get the handler and predicates at its construction time rather than at Start
time, because using Start
entails passing it through the controller
and that would entail that we can only support one type per controller.
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 see, I'll work on it
PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Fixes #2214