Codec

[Tony Morris]

Mark,
What was our reasoning to split out Encode/Decode into separate traits?
I can only remember something like, "because there may be values that go
one way and not the other." I cannot make this make sense in my head.
Sorry if I have forgotten -- I was on heavy drugs.

--
Tony Morris
http://tmorris.net/

[Mark Hibberd]

On Dec 30, 2012 8:29 PM, "Tony Morris" <tonym...@gmail.com> wrote:
>
> Mark,
> What was our reasoning to split out Encode/Decode into separate traits?
> I can only remember something like, "because there may be values that go
> one way and not the other." I cannot make this make sense in my head.

Couple of things.

You want to be able to use the (non-) existence of the encode to control serialisation of sensitive data. For example not including an EncodeJson for data structure that includes a password.

And more loosely while it makes sense for Encode/Decode pairs for all primitives. As you build things out you end up with (or should if you are not being sloppy with specifying things) lots of specific data types that only get used for one direction. For example, a basic CRUD scenario, the data type for updating the structure will likely be looser (having optional fields) then the read structure which will have all fields as mandatory. So given that you want to encode these scenarios as different data types to keep things tight, you also only want to have the precise encode or decode that each type should be used for.

Outside of this, we have previously talked about providing facilities in the library for helping to define the encode and decode together when desired. For example, something like json5L(....) that defines an encode decode pair. I think this is a good (essential even) idea to make everything more coherent.

Offline at the moment, just on phone, so apologies if any of the above is incoherent. Will be back on irc tonight if you want to catch up on it further.

Mark.

[Tony Morris]

Coolo. Thanks mate. It makes a lot more sense now. I agree there should be something like: EncodeJson, DecodeJson and CodecJson.

FWIW, I have generalised this "serialisation" using Haskell, without specifics to JSON, and a lot of obvious things have become apparent, including the latter need for the three data types.