Implement getField CEL function #225
Conversation
I think it has to be a global overload, a member overload would require a generic on the receiver which doesn't seem possible. I'm proposing this as an eventual replacement (before 1.0) of our hack around the fact that the `in` identifier is reserved in CEL. This is especially urgent for protovalidate-cc which is currently carrying patches to the CEL implementation in order to enable it, since cel-cpp doesn't allow this sort of functionality to be added in at runtime.
|
The latest Buf updates on your PR. Results from workflow Buf / validate-protos (pull_request).
|
ghost
mentioned this pull request
ghost
marked this pull request as ready for review
cel/library.go
Outdated
| cel.AnyType, | ||
| cel.FunctionBinding(func(values ...ref.Val) ref.Val { | ||
| message, ok := values[0].Value().(proto.Message) | ||
| message, ok := values[0].(interface{ Get(index ref.Val) ref.Val }) |
|
Also, re:
If you make the receiver type dyn, I think it would work? |
This is a proposal to remove our hack around the fact the `in` identifier is reserved in CEL. This is especially urgent for protovalidate-cc which is currently carrying patches to the CEL implementation in order to enable it, since cel-cpp doesn't allow this sort of functionality to be added in at runtime. Runtime PRs: - Go: bufbuild/protovalidate-go#225 - C++: bufbuild/protovalidate-cc#90 - Python: bufbuild/protovalidate-python#290 - Java: bufbuild/protovalidate-java#271
|
Oops, I saw this after me and Nick moved to merge the protovalidate PR. I've been pondering but I think it's not worth losing too much sleep over; we're still pre-1.0 so we can always try to make this prettier later, especially since the protovalidate protobuf descriptors used for standard constraints are always strongly tied to the implementation version. (I think if we try to do that, most likely we'd run into problems with at least some of the CEL runtimes, whereas this approach works on all five. That said, we can workshop it. If we really hate free functions we could always do something evil like |
1 participant
I think it has to be a global overload, a member overload would require a generic on the receiver which doesn't seem possible.
I'm proposing this as an eventual replacement (before 1.0) of our hack around the fact that the
inidentifier is reserved in CEL. This is especially urgent for protovalidate-cc which is currently carrying patches to the CEL implementation in order to enable it, since cel-cpp doesn't allow this sort of functionality to be added in at runtime.Protovalidate PR: bufbuild/protovalidate#352