qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH v1 2/8] qapi: golang: Generate qapi's alternate types in


From: Daniel P . Berrangé
Subject: Re: [RFC PATCH v1 2/8] qapi: golang: Generate qapi's alternate types in Go
Date: Tue, 10 May 2022 12:28:40 +0100
User-agent: Mutt/2.1.5 (2021-12-30)

On Tue, May 10, 2022 at 01:21:29PM +0200, Victor Toso wrote:
> Hi,
> 
> On Tue, May 10, 2022 at 11:10:45AM +0100, Daniel P. Berrangé wrote:
> > On Sat, Apr 02, 2022 at 12:40:58AM +0200, Victor Toso wrote:
> > > This patch handles QAPI alternate types and generates data
> > > structures in Go that handles it.
> > > 
> > > At this moment, there are 5 alternates in qemu/qapi, they are:
> > >  * BlockDirtyBitmapMergeSource
> > >  * Qcow2OverlapChecks
> > >  * BlockdevRef
> > >  * BlockdevRefOrNull
> > >  * StrOrNull
> > > 
> > > Alternate types are similar to Union but without a
> > > discriminator that can be used to identify the underlying
> > > value on the wire. It is needed to infer it. That can't be
> > > easily mapped in Go.
> > 
> > I don't buy that. Given this example:
> > 
> >   type BlockdevRef struct {
> >         // Options are:
> >         // * definition (BlockdevOptions): defines a new block device inline
> >         // * reference (string): references the ID of an existing block 
> > device
> >         Value Any
> >   }
> > 
> > What is the problem with having this Go struct:
> > 
> >   type BlockdevRef struct {
> >         Definition *BlockdevOptions
> >           Reference  *string
> >   }
> 
> ... this is better.
> 
> > when deserializing from JSON, we know exactly which one of
> > these two fields to populate. The programmer consuming this can
> > look at which field is non-nil.
> > 
> > When serializing to JSON, we serialize which ever field is
> > non-nil.
> > 
> > If both fields are non-nil that's a programmer bug. Either
> > ignore it and only serialize the first non-nil field, or raise
> > an error.
> 
> It would be a programmer bug if they set a Value of a type not
> allowed by Type's spec, but it would be a *runtime* error. Your
> suggestion is more type safe.

Yep, essentially I'm saying I want the code to enable type
checking to be done at compile time instead of runtime,
whenever it is possible to achieve that from a technical POV.


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 :|




reply via email to

[Prev in Thread] Current Thread [Next in Thread]