Andrea Bolognani <abologna(a)redhat.com> writes:
On Mon, 2019-05-13 at 13:19 +0100, Daniel P. Berrangé wrote:
> On Mon, May 13, 2019 at 02:00:28PM +0200, Andrea Bolognani wrote:
> > One possible complication is that we would not be able to use any
> > of the GLib types in our public API... I think the way we should
> > approach this is to consider the current public API as if it were
> > yet another language binding, the language being plain C in this
> > case, and make sure we have a very well defined boundary between
> > them and everything else, basically treating them as a separate
> > project that just so happens to live in the same repository and be
> > developed in tandem. This should also make it easier for us to
> > switch to a different programming language in the future, should
> > we decide to.
>
> I'm not sure why you say we can't use GLib types in our public API ?
>
> I think we could use them, but I'd probably suggest we none the less
> choose not to use them in public API, only internally :-)
>
> But I'm anticipating we could replace virObject, with GObject, and as
> such all the virXXXXXPtr types in our public API would become GObjects.
> I think we'd likely keep them as opaque types though, despite the fact
> that they'd be GObjects, to retain our freedom to change impl again
> later if we wish.
>
> I won't think we need to change use of 'long long' to 'gint64',
etc
> Not least because because GLib maintainers themselves are questioning
> whether to just mandate stdint.h types.
Interesting. Got a link?
> This is fairly minor
though.
I was mostly thinking about this latter example and other situations
along those lines. For example, we'll definitely need to start using
gchar* internally,
Are you sure about "definitely"? gchar is merely a typedef name for
char...
and since we don't want that implementation
detail
exposed in our plain C bindings,
Yup, letting GLib's typedef names for ordinary C types leak into your
public headers would be a mistake.
then we'll have to do at least
some
very lightweight conversion (casting) between that and char*. This is
one of the examples where considering the existing API as a language
binding would IMHO result in a maintainable structure.
[...]