Re: [RFC PATCH v1 0/8] qapi: add generator for Golang interface

["Daniel P. Berrangé" <berrange@redhat.com>]

On Mon, May 02, 2022 at 10:01:41AM -0400, Andrea Bolognani wrote:
> > Times how many naming conventions?
> 
> Yeah, I don't think requiring all possible permutations to be spelled
> out in the schema is the way to go. That's exactly why my proposal
> was to offer a way to inject the semantic information that the parser
> can't figure out itself.
> 
> Once you have a way to inform the generator that "VNCProps" is made
> of the two words "vnc" and "props", and that "vnc" is an acronym,
> then it can generate an identifier appropriate for the target
> language without having to spell out anywhere that such an identifier
> would be VNCProps for Go and VncProps for Rust.
> 
> By the way, while looking around I realized that we also have to take
> into account things like D-Bus: the QAPI type ChardevDBus, for
> example, would probably translate verbatim to Go but have to be
> changed to ChardevDbus for Rust. Fun :)

The hardest one of all is probably

   QAuthZListPolicy

which must be split  'QAuthZ'  + 'List' + 'Policy'  - the trailing
uppercase ruins all heuristics you can come up with, as there's no
viable way to distinguish that scenario from 'ChardevDBus' which
is 'Chardev' + 'DBus' not  'ChardevD' + 'Bus'

> Revised proposal for the annotation:
> 
>   ns:word-WORD-WoRD-123Word

Ugly, but we should only need this in the fairly niche scenarios,
so not too pain ful to add a handful of these:

Essentially if have the schema use CamelCase with UPPERCASE
acronyms, and declare two rules:

 1. Split on every boundary from lower to upper
 2. Acronym detection if there's a sequence of 3 uppercase
    letters, then split before the last uppercase.

then we'll do the right thing with the vast majority of cases:

  ChardevSocket:
     Rule 1: Chardev + Socket
     Rule 2: Chardev + Socket

  VNCProps:
     Rule 1: VNCProps
     Rule 2: VNC + Props

  ChardevDBus
     Rule 1: Chardev + DBus
     Rule 2: Chardev + DBus

and fail on 

  QAuthZListPolicy

     Rule 1: QAuth + ZList + Policy
     Rule 2: QAuth + ZList + Policy

so only the last case needs   ns:QAuthZ-List-Policy  annotation, whcih
doesn't feel like a big burden


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|