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
From my node-schema talks with @warpfork, I've come to understand that a struct's MapIterator will only skip optional fields which are absent when one is using the node's representation. It seems to be by design that, without the representation view, absent fields are included.
I agree it seems inconsistent that the non-repr node then does not allow assigning null. I think it should be a property that marshaling a node with a well-designed codec, and unmarshaling back into the same node's prototype, should not error. I'm less sure that it should give exactly the same data in memory, but at least decoding shouldn't error if encoding worked.
I think, in practice, everyone is expected to use representation nodes when encoding, and representation prototypes when decoding. A few weeks ago I argued that this should be done by default by all codecs, but Eric mentioned that maybe one does want to encode or decode a node without its repr view, e.g. for debugging purposes. Though I do personally think that the codecs should, by default, choose the repr view.
Re: unmarshalling back into the same node prototype: yeah, I agree that no matter what, we should get this to be more symmetrical. I'm afraid unmarshalling symmetrically isn't generally possible though: if there was a field that's optional nullable (both) then the coersion of absent to null was a lossy one.
Suppose you have a struct define as
and you serialize it:
This will serialize (with the link prototype being dagjson) to
which.. is wrong?
on attempting to decode it, it will then fail.
The text was updated successfully, but these errors were encountered: