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
In addition to existing choices, including pseudo-value of ANY (which is similar to null as annotations do not allow explicit null value), it would make sense to add something to indicate use of the "most natural" binding (in case where there are more than one physical shape, but different structure; mostly for OBJECT, but possibly also ARRAY or even STRING), or, in case of type extensions, an alternative underlying format. An example of latter would be binary type (matching byte[]) that some formats (like Smile, CBOR, Protobuf) support.
While it would also be possible to add explicit BINARY type, it seems better use a logical higher-level concept of "NATIVE" or "NATURAL", since this can be used for all kinds of underlying "exotic" types; for example, type menagerie exposed by BSON.
Of choices, NATURAL seems slightly preferable.
The text was updated successfully, but these errors were encountered:
cowtowncoder
changed the title
(2.7) Consider adding new choice for JsonFormat.Shape, maybe NATIVE or NATURAL
(2.8) Consider adding new choice for JsonFormat.Shape, maybe NATIVE or NATURALDec 11, 2015
cowtowncoder
changed the title
(2.8) Consider adding new choice for JsonFormat.Shape, maybe NATIVE or NATURAL
Add new choice for JsonFormat.Shape, NATURALMay 20, 2016
(for background, see FasterXML/jackson-databind#865)
In addition to existing choices, including pseudo-value of
ANY
(which is similar tonull
as annotations do not allow explicit null value), it would make sense to add something to indicate use of the "most natural" binding (in case where there are more than one physical shape, but different structure; mostly forOBJECT
, but possibly alsoARRAY
or evenSTRING
), or, in case of type extensions, an alternative underlying format. An example of latter would be binary type (matchingbyte[]
) that some formats (like Smile, CBOR, Protobuf) support.While it would also be possible to add explicit
BINARY
type, it seems better use a logical higher-level concept of "NATIVE" or "NATURAL", since this can be used for all kinds of underlying "exotic" types; for example, type menagerie exposed by BSON.Of choices,
NATURAL
seems slightly preferable.The text was updated successfully, but these errors were encountered: