Re: [RFC PATCH v1 4/8] qapi: golang: Generate qapi's union types in Go

["Daniel P. Berrangé" <berrange@redhat.com>]

On Tue, May 10, 2022 at 01:32:08PM +0200, Victor Toso wrote:
> Hi,
> 
> On Tue, May 10, 2022 at 11:26:56AM +0100, Daniel P. Berrangé wrote:
> > On Sat, Apr 02, 2022 at 12:41:00AM +0200, Victor Toso wrote:
> > > This patch handles QAPI union types and generates the equivalent data
> > > structures and methods in Go to handle it.
> > > 
> > > At the moment of this writing, it generates 67 structures.
> > > 
> > > The QAPI union type can be summarized by its common members that are
> > > defined in a @base struct and a @value. The @value type can vary and
> > > depends on @base's field that we call @discriminator. The
> > > @discriminator is always a Enum type.
> > > 
> > > Golang does not have Unions. The generation of QAPI union type in Go
> > > with this patch, follows similar approach to what is done for QAPI
> > > struct types and QAPI alternate types.
> > 
> > The common way to approach unions in Go is to just use a struct
> > where each union case is an optional field, and declare that
> > only one field must ever be set. ie
> > 
> >   type SocketAddressLegacy struct {
> >         // Value based on @type, possible types:
> >         Inet *InetSocketAddressWrapper
> >         Unix *UnixSocketAddressWrapper
> >         VSock *VsockSocketAddressWrapper
> >         FD *StringWrapper
> >   }
> 
> Like Alternates, I like this better.
> 
> > When deserializing from JSON we populate exactly one of the
> > optional fields.
> > 
> > When serializing to JSON process the first field that is
> > non-nil.
> > 
> > Note, you don't actually need to include the discriminator as a
> > field at all, since it is implicitly determined by whichever
> > case is non-nil.  Introducing the discriminator as a field just
> > provides the possibility for the programmer to make
> > inconsistent settings, for no gain.
> 
> Sounds reasonable. We still need to implement Marshal/Unmarshal
> for unknow types (e.g: a new Type for SocketAddressLegacy was
> introduced in 7.1 and we should be able to know that current
> qapi-go version can't understand it).

If there's a new type seen on the wire then, the easy
option is to just not deserialize it at all. Return
a SocketAddressLegacy struct with all fields nil, or
perhaps return a full 'error', since this is likely
to be significant functionalproblem for the application. 

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|