Replies: 2 comments
-
ℹ️ FYI, I am not against or pro any concrete direction. I am just trying to bounce as many ideas around and challenge them, in order to test them and arrive at the best solution possible. And I am glad, I don't have to do it alone 😬 Point 1
Yes, I am not arguing for keeping the enums (even though there are cool in Swift).
Yes right. However, one could argue that the current So, these resources can be modelled by an enum, and maybe the custom resources by another enum or struct, and if you want to extend the client for And as you said, everything is a resource, and the resource should define its On the other hand, the client doesn't care about the resource and it can treat every one of them via the type-erased
So basically, the only thing the client requires is this
Yes, Again, this is not an argument for the enums. In summary: Using a struct here, with helper static properties for the known GVKs seems like a good fit. Got to go now but I'll address Point 2 and 3 and the other points from the PR later 😸 |
Beta Was this translation helpful? Give feedback.
-
Point 2
The idea behind introducing a new marker protocol is hide complexity by providing an explicit extension point and being explicit with the intent, i.e. a CRD is an API resource, which is always readable, writable, deletable etc., so why should the library user concern himself with these details instead of just conforming to Having said that, the new marker protocol would be an additive change, which we don't have to do right away, but rather introduce later if the need for it arises. So maybe it could wait. Point 3
Yes, that shouldn't be a problem, especially if we switch to using a struct for GVK or GVR. |
Beta Was this translation helpful? Give feedback.
-
Initial ideas and WIP implementation are in this PR #2
Ideas until now
GroupVersionKind
to a struct type vs. an extra enum case.custom
vs.
CustomResource
vs. why bother?Beta Was this translation helpful? Give feedback.
All reactions