The current implementation, based on CEL-Go, implicitly converts every enum-value to a raw int type. "Raw int type" means, that it loses contextual information that the int value is actually the ordinal of an enum-type and therefore it is currently only possible to compare enum-type-properties against an int or the fully-qualified enum. For example these CEL expressions work: someobject.enum_field == 123 and someobject.enum_field == org.projectnessie.cel.demo.EnumType.ENUM_VALUE , but an expression like someobject.enum_field == 'ENUM_VALUE' does not work, because if would compare an int with a string.
Making enum-types first-class citizens in the type system, i.e. add an org.projectnessie.cel.common.types.EnumT, would allow comparing against a string and even iterate over its values.
The implementation of EnumT is somewhat similar to ObjectT. It returns the message (type) name of the enum as its type name.
It is important to maintain the current backward/forward compatibility with enum values at least for protobuf (with the ProtoTypeRegistry) - i.e. allow arbitrary enum ordnial values that are not defined or are negative.
For Java (with the JacksonRegistry) it probably does not make a lot of sense to allow querying enum-type attributes - i.e. JavaBean-getters defined in the Java enum. In fact, what such getters returns actually depends on the current enum implementation, which is not a portable thing.
With this change, the conformance tests for enums, which are currently skipped, should be enabled.
See also:
/cc @nastra
The current implementation, based on CEL-Go, implicitly converts every enum-value to a raw
inttype. "Rawinttype" means, that it loses contextual information that theintvalue is actually the ordinal of an enum-type and therefore it is currently only possible to compare enum-type-properties against anintor the fully-qualified enum. For example these CEL expressions work:someobject.enum_field == 123andsomeobject.enum_field == org.projectnessie.cel.demo.EnumType.ENUM_VALUE, but an expression likesomeobject.enum_field == 'ENUM_VALUE'does not work, because if would compare anintwith astring.Making enum-types first-class citizens in the type system, i.e. add an
org.projectnessie.cel.common.types.EnumT, would allow comparing against a string and even iterate over its values.The implementation of
EnumTis somewhat similar toObjectT. It returns the message (type) name of the enum as its type name.It is important to maintain the current backward/forward compatibility with enum values at least for protobuf (with the
ProtoTypeRegistry) - i.e. allow arbitrary enum ordnial values that are not defined or are negative.For Java (with the
JacksonRegistry) it probably does not make a lot of sense to allow querying enum-type attributes - i.e. JavaBean-getters defined in the Javaenum. In fact, what such getters returns actually depends on the current enum implementation, which is not a portable thing.With this change, the conformance tests for enums, which are currently skipped, should be enabled.
See also:
/cc @nastra