Re: [Xen-devel] [RFC] Generating Go bindings for libxl

[Nicholas Rosbrook <rosbrookn@xxxxxxxxxxxx>]

> Yes, I think that's really the only option.  Poking around, it looks
> like a lot of different people have recommended it; and the fact that
> it's in use by gRPC means it can't be too terrible a solution.

Yeah, having worked with generated gRPC code I don't think it's too bad.

> The interface type itself will need to be exported, right?  (Obviously
> we don't want to export the defining method.)

No actually, a struct field can be exported without its type being exported.
The code generated for gRPC does exactly that. It looks a little bit weird,
but it makes sense to do that in this scenario.

> So you've named the struct after the name of the key (libxl_domain_type)
> and the key value (hvm); but I don't think that's sufficient.  Already
> there are two different structures indexed by libxl_channel_connection:

Noted. I hadn't actually thought through the specifics of naming yet.

> ...and then I'm afraid you'd need to have 'Dts' (should be exported,
> right?) instead by the element specified by the IDL; so 'U' in all the
> current cases.

Yes, the field name needs to be exported unless we wanted to provide
getters/setters.

> I think the second one looks prettier.  (Actually I think using 'u' as
> the element name for the union was kind of a bad idea in the first
> place.)  But that does mean we're 'overriding' the instructions of the
> IDL (which prescribe both the key element name and the union element name).
> 
> What do you think?  If like me, you prefer the second one, I'll try to
> ping Ian Jackson to make sure he doesn't have any objections to it.

I agree, the second one looks better, except we won't export the interface type.

-NR
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel