Yes, a similar question came up in an internal discussion as well.
> Consider we have a Color class which represents a color in RGB format:
>
> class Color { private final int rgb; }
>
> The most obvious and efficient way to serialize/deserialize its state is to
> extract this int field:
>
> It's great for binary serialization. However if I serialize to JSON I would
> not like to see `color: 16711680`. JSON or XML are intended to be at least
> partially human-readable. So probably I want to see `color: red` or at least
> `color: #FF0000`. Well no problem, we can alternatively serialize as string:
Good example. There’s no problem in the model with multiple serializers, but
it raises the question: how would a client select which form? Suppose instead
of (or in addition to) the version property on the annotation, we had some
other selectors. Suppose for sake of argument that Color has the following
serializers:
@Serializer(selector = “binary”)
public pattern Color(int colorValue) { … }
@Serializer(selector = “text”)
public pattern Color(int r, int g, int b) { … }
These tags are selected by the author of Color at development time. But the
ultimate user of serialization is someone in some other maintenance domain,
asking to serialize a whole graph that has colors in it. Without some sort of
global agreement on the taxonomy of selectors, a given graph might have many
classes which reflect the text/binary distinction (just one possible
distinction) in a dozen different ways. And the tex/tbinary distinction might
not be the only distinction one wants to reflect; one could imagine varying
degrees of detail preservation, for example.
So I like the idea of treating the set of serializers as something that can be
queried over by a serialization library — the question is — what is the
structure of these queries, such that would-be queriers don’t have to “join”
100 different “tables” each with their own schema style?
