[libvirt] [libvirt-go PATCH 0/3] Introduce recent DomainSnapshotXML and DomainSaveImageXML flags

[Daniel P. Berrangé]

On Fri, Feb 22, 2019 at 10:54:10AM -0600, Eric Blake wrote:
> On 2/22/19 10:43 AM, Daniel P. Berrangé wrote:
> > On Fri, Feb 22, 2019 at 04:32:27PM +0100, Erik Skultety wrote:
> >> Unfortunately, in order to support the new flags, the last patch introduces an
> >> API breakage as the convention we use for the bindings is to also enforce types
> >> for flags.
> > 
> > Yes, unfortunately this need to break ABI is fallout resulting from
> > my decision to make the Go bindings do stricter enum validation that
> > we have had at the C level.
> > 
> > On balance I think that is still the right tradeoff to have stronger
> > type checking as it catches real errors in app code.
> 
> I'm fine with that decision.  I will note, however, that this website
> suggests an interesting approach:
> 
> http://changelog.ca/log/2015/01/30/golang
> 
> A variadic function using ...interface{} can accept arbitrary types for
> the optional parameters, and then open-code its own type-checking to
> ensure that the user complied with the intended use-cases.  If the flags
> parameter can be accepted through that type of trick, coupled with
> validation that the caller never passed more than one argument for
> flags, and that the passed argument is typed solely as one of the two
> expected enums, then you can maintain API compatiblity, even though the
> ABI changes to a variadic instead of a strictly-typed flags argument.  I
> don't know if it is worth doing, though.

Yes interface{} is a clever trick serving a vaguely similar purpose to
allowing a 'void*' in C, but with benefit that the method can actually
do some real type checking. The downside is that this is now runtime
type checking, not static compile time.

So I think on balance I'd still prefer the static checking and accept
the breakage, as it is a win in the long term with only small amount
of short term pain.

> > Due to the widespread use of "vendoring" in the Go community where
> > apps fixate on specific git commit hashes of their dependandancies,
> > the fallout is more limited and will mostly only impact devs at the
> > time they decide to explicitly sync to newer git.
> > 
> 
> And this is a good argument for not being upset about the API break and
> therefore not worrying about trying to use variadic functions to give
> back-compat.
> 
> (For the record, the nbdkit project specifically documents that its C
> API/ABI will be kept compatible, but warns that other language bindings
> API may break, precisely to account for cases like this where there is a
> mismatch between C semantics and the slightly different idioms of the
> other languages).

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