Use CBOR tags to disambiguate which struct to fill an interface field with

[rayhaanj]

If a struct like the following is passed to the Unmarshaler, then it is unclear as to how the unmarshaler would know which concrete type to fill into the struct field:

type ConvolutedIndirectable interface {
  ConvolutedIndirection() int
}

type Indirector struct {
  I int
}

func (i *Indirector) ConvolutedIndirection() int {
  return i.I
}

type One struct {
  A ConvolutedIndirectable
}

func main() {
  reader := ...
  var o One
  if err := reader.Unmarshal(&o); err != nil {
    ...
  }
}

When the struct is marshaled the information about what struct was actually in the interface is lost, only an un-type-annotated map is transferred via CBOR, so it does not seem possible to work out what type to create to put in this field when unmarshaling.

[britram]

tl;dr This is what CBOR tags are for.

In the case that there is not enough semantic information in the CBOR object to determine what Go type an object needs to be (where this semantic information can come from the containing object, as in the RAINS message case, where the message section type is defined by the content of the section), that object should be preceded with a tag.

Missing from Read() is an option to interpret a CBORTag as a type prefix. This would require the addition of tag registry (maybe in typeinf.go) that mapped tags to constructors of structs that implement CBORUnmarshaler. Read() would then, before returning a tag, check its tag registry to determine if it had a registered unmarshaler, and if so, pass the stream after the tag to said unmarshaler.

We could use this to handle timestamps automatically, as well as to allow Read() to return RAINSMessage objects based on the RAINS tag, see the RAINS spec and https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml.

(Will leave it up to @rayhaanj as whether you want this as a separate issue, or just want to mutate this issue to be about tag reading. I can also drop by CAB before the group meering to discuss if it'd be helpful)

[rayhaanj]

I delved too deep into the reflection that I forgot about CBOR tags. I'll work on using tags to disambiguate the structs that go into interfaces, that seems like a nice solution (and rename this issue to that).

[rayhaanj]

Been going back and forth on this for a while, but it seems that it is unnecessary to have the registered structs themselves implement CBORUnmarshaler since if we already know which constructor to use then we might as well use the automatic struct decoding on that struct.

The problem is knowing which struct is being read in, and this can simply be done within borat itself, however will require the map parser to be changed to return a map which contains potentially tagged items. Then the struct reader can interpret the tag and choose the appropriate structure to unmarshal into. If the map is just being read as a normal map then the optionally tagged items can be converted into untagged items and returned to the caller.

So I'll clean up and follow this plan now.

[geoah]

I do apologise if this is the wrong place to ask but would this also allow borat to tag structs? And if so is this something that is being worked on?

Thank you :)