Zulu-Inuoe
commented
3 months ago Your observations are correct. Currently there is no procedure to hook and extend deserialization at the parsing level. You are free to implement your own coercion facility on top of the standardized return types (hash table, vector, etc). I'd like to come up with a good API for providing deserialization but haven't landed on anything I like. Even the custom serialization that exists is something I strongly dislike. I have some notes over in https://github.com/Zulu-Inuoe/jzon/issues/7, and had some experiments with it, but nothing I felt comfortable putting out for the lib
Customized serialization is supported by the generic function write value, which allows me to specialize both on value (the lisp type of value being written) and on writer -- which allows me to have a subclass of the basic WRITER class which can carry information about the context in which the value being written was encountered. So, e.g., I could serialize a STRING value "06/12/2010" as a json object in a context where that string was being used to represent a date and I have agreed with the consumers of the serialization that dates are serialized as json object with specific properties.
A corresponding capability for custom deserialization is missing, insofar as I can see. Although PARSER is a CLOS class that I can subclass and use to hold context telling me how to deserialize a value, I do not find any generic functions having a specializable formal parameter that might given a parser instance as the actual parameter. So if I reach point in parsing where I know the next json value should be the agreed-upon json object serialization for a date, I don't have any way to write a CLOS method that will produce the lisp string value in the result.
[Nothing special about STRINGs here, the same argument holds if the lisp application is representing dates as clos object in the LOCAL-TIME library. It is easy to get the serialization I want, but not to get the parser to produce the deserialization value.]