On Fri, Feb 22, 2019 at 10:39:06AM -0600, Eric Blake wrote:
On 2/22/19 9:32 AM, 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.
Oh bummer - I didn't realize that some of the other language bindings
are more strongly typed than our C APIs. We should probably audit to
see if we have any other APIs with foolishly reused enum types that
should instead be given their own flag type.
Go isn't inherantly more strongly typed. We could have just stuck with
uint32 for the Go bindings following libvirt, but I made the concious
decision to define Go types for all flags and use them in methods.
Generally this isn't a problem as changing from uint32 to a strong
type is backcompatible when we've had an unsed flags argument for
a method.
This situation where we changed the enum for flag for an existing
API is thankfully rare, and the benefits of strong typing thus
outweighs the occassional API breakage cost.
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 :|