TypeCodec

[isoos]

No description provided.

[isoos]

/cc @simolus3: This PR and #348 is a work towards #346 (and extensibility in general). The current PR has TypeCodec separately from Type, but in the end I see little to no benefit separating them: the encode and decode methods may live on the Type object, so next iteration would be just Type with the two extra methods. I also think that the current encode/decode method signatures may be stable (with the context being extensible). Any comments on the design or insight wrt. package:drift compatibility?

[simolus3]

Drift doesn't use the TypeCodec directly, so as long as we're still able to specify the types to use for parameters, that doesn't cause any incompatibilities.

but in the end I see little to no benefit separating them: the encode and decode methods may live on the Type object, so next iteration would be just Type with the two extra methods

IIRC we had that distinction in the v2 API and I've carried that over to the initial v3 implementation so that it doesn't have to be part of the public API (which types are). But now since that appears to stand in the way of supporting more complex types / OID caches, I agree that just moving that functionality to Type directly makes sense.

[isoos]

IIRC we had that distinction in the v2 API and I've carried that over to the initial v3 implementation so that it doesn't have to be part of the public API (which types are). But now since that appears to stand in the way of supporting more complex types / OID caches, I agree that just moving that functionality to Type directly makes sense.

I'm a bit undecided on this. It would make sense to move the method to the Type class. As an alternative, we could migrate the Type to be an extension type on int (meaning it is just the OID value, while we keep the current methods), while the codec methods (including the custom type methods) remain separate (and the TypeRegistry may take them as a constructor parameter (e.g. Map<int, TypeCodec>)

[isoos]

The more I think of it, the more I'm for separating the Type from the two methods. It keeps more options open:

• the methods could be added to Type later if really needed
• Type could be migrated to int-based extension type (pure OIDs)
• encode and decode may have a selective override (for special cases which we may not want to support)