Uh oh!
There was an error while loading. Please reload this page.
Introduce MessageReflector to enable alternative protobuf runtimes - #132
Introduce MessageReflector to enable alternative protobuf runtimes#132andrewparmet wants to merge 0 commit into
Conversation
35bf1b7 to
7928e60CompareUh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
| return clazz.cast(value); | ||
| @Nullable | ||
| public <T> T jvmValue(Class<T> clazz) { | ||
| return null; |
There was a problem hiding this comment.
Is this not used by anyone? Could we not keep it returning the underlying Message as before?
Do we need to make smaller interfaces and only implement jvmValue on Value types that provide a valid implementation?
There was a problem hiding this comment.
Correct, this is not used. jvmValue is used for fields that protovalidate-java validates directly itself, like enums (as opposed to passing into CEL), and right now it does not do any validation on message types.
See also the changed doc on Value.jvmValue.
There was a problem hiding this comment.
But even if it did, it doesn't make much sense to cast the message type to anything, does it? This hints at the narrower interface you mention.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
88684a4 to
5efed01CompareRight now the validator eagerly converts the protokt message to a protobuf DynamicMessage. With bufbuild/protovalidate-java#132, this can [change to supply a wrapper](0cd3157) around the protokt message that only converts as requested by the validator. Not sure if this module belongs at the top level or in third-party. In that case, maybe the gRPC modules also belong in third-party. For example, supposing protokt one day supports the [Connect](https://connectrpc.com/) protocol, that would also go in third-party, but it feels like a sibling to gRPC. Fixes#207.
see #80
see open-toast/protokt@0cd3157 for what the implementation looks like given this PR