[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3-RESEND 03/28] libxl: ocaml: avoid reserved words in type and field names.

On Thu, 2013-10-24 at 23:11 +0100, Rob Hoes wrote:
> On 24 Oct 2013, at 23:04, Ian Campbell <ian.campbell@xxxxxxxxxx>
>  wrote:
> > On Mon, 2013-10-21 at 14:32 +0100, Rob Hoes wrote:
> >> Do this by adding a "xl_" prefix to all names.
> > 
> > Does this not result in pretty fugly looking ocaml code with lots of
> > spurious "xl_" everywhere?
> Yesâ I'm not too happy about that, but I think it is the only easy
> enough way of making this transformation "injective", as IanJ
> suggested.

If the result of making the transformation injective is that the ocaml
code looks like libxl.xl_domain_build.xl_max_memkb then I think the cure
has been worse than the disease.

I would suggest that if libxl has a structure which has both type and ty
fields then we have a bug in our API due to the use of confusingly
similar field names which are not easily discriminated i.e. they should
have been foo_type and bar_type (but perhaps due to API stability they
would have to be type and bar_type in practice).

The approach used here could be made slightly more palatable by only
applying it to names of the form "([prefix])*[keyword]", by applying a
new prefix. i.e. type -> xl_type -> xl_xl_type.

>  The alternative would be to change the munge function on a
> case-by-case basis, e.g. whenever someone adds a name which happens to
> be an OCaml keyword to the libxl IDL.

There aren't all that many ocaml keywords, I suppose? I expect many of
them are unlikely field names. If we don't want to enumerate them up
front (which I would accept, it's a bit tedious) I'd be perfectly happy
to fault things in as the libxl IDL gains new inconveniently named
fields, it'll break the build so we should notice pretty quickly!


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.