[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.

It's not quite that bad, because it is only needed for lower-case stuff and 
therefore excludes module names. Your example would be 
"Xenlight.Domain_build_info.xl_max_memkb". But yes, it does make things look a 
bit odd.

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

I'd be very happy with that, if it is acceptable to you and IanJ!

Cheers,
Rob

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

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