Having a dedicated API to define index field types, or encodings, regardless of when and where that encoding is used, could help in several ways:
Dynamic field APIs could re-use this encoding definition API, or require an encoding to be passed when defining a dynamic field; see
We could make ValueBridge#bind cleaner by passing it interfaces from the encoding definition API instead of the field definition API (i.e. the ValueBridge would no longer be able to create an accessor)
Below is a concrete example; instead of having this:
… we would probably have something like this:
Then when dynamic fields get introduced (HSEARCH-3273), we can also reuse the encoding definition API, i.e.:
Related: HSEARCH-3217. Maybe it should be closed as obsolete, maybe it is still relevant for the encoding definition API.