You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should take all the default serialization features of DazzleConf and turn them into value serializers. That way, developers can swap out which serialization mechanisms are used. The default serializers, however, should follow existing DazzleConf practices and require no manual configuration.
This will require us to allow some serializers to match multiple kinds of types. For example, serializing enums must check whether the type is an enum.
The text was updated successfully, but these errors were encountered:
We need to consider conflicts in case the developer registers value serializers which apply to common types, as can happen if wildcard matching is employed. Detecting conflicts correctly would be difficult.
Fortunately, developers should rarely need wildcard matching and should understand when doing so. It should be sufficient to scan the serializers until a matching one is found, giving prioritization to later-added serializers so that developers can override the inbuilt serializers easily. For example, I might want to override the inbuilt serialization for one of my enum classes by supporting different names for a variant, but retain default handling for all the other enums.
To assist debugging, we can print the associated value serializer when a user specifies an invalid value. This will be possible easily thanks to colocation of serializer instance with node entry (a detail buried in #40).
Value serializers should be provided a definition cache so that configuration definitions do not need to be passed into them. Then, any serializer implementation may request sub-sections following the classic DazzleConf style. This will therefore enable us to completely implement all serialization in terms of the value serializer model.
We should take all the default serialization features of DazzleConf and turn them into value serializers. That way, developers can swap out which serialization mechanisms are used. The default serializers, however, should follow existing DazzleConf practices and require no manual configuration.
This will require us to allow some serializers to match multiple kinds of types. For example, serializing enums must check whether the type is an enum.
The text was updated successfully, but these errors were encountered: