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