[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! Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |