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

[Markus Armbruster]

Daniel P. Berrangé <berrange@redhat.com> writes:

> 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 :)

For what it's worth, I prefer Rust's style, because I hate downcasing
tails of abbreviations a lot less than I hate WORDSRUNTOGETHER.

> 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

Rule 2 isn't used here.

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

Rule 2 is used here.

For Rust-style VncProps, rule 2 is again unused.

>
>   ChardevDBus

Note: "DBus" is not an (upper-case) acronym.  It's a proper name grown
from an abbreviation of "desktop bus".

>      Rule 1: Chardev + DBus
>      Rule 2: Chardev + DBus

Rule 2 isn't used here, either.

> 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

I think there are two interesting sub-problems within the larger problem
of mapping QAPI names to "nice" target language identifiers.

1. Splitting words run together (mostly camels, but also mistakes like
   logappend).

2. Adjust case in words for the target language

For 1., we can rely on word separators '-', '_' and change from lower to
upper case.  Cases where that doesn't suffice remain.

Adopting Go-style camels for QAPI will add to them, but something like
your rule 2 above should mitigate.

What about this simple greedy algorithm:

    funny_words = [QAuthZ, ...]

    tail = name
    words = []
    while tail != "":
        if tail starts with any of the words in funny_words:
            next_word = that member of funny_words
        else:
            next_word = tail up to next separator or change from lower
                        to upper case
        append next_word to tail
        tail = remainder of tail with leading separator stripped

For 2., adjusting to all lower case (like "vnc", "props", "dbus"), all
upper case (like "VNC", "PROPS", "DBUS"), and capitalized (like "Vnc",
"Props", "Dbus") is trivial.  Adjusting to capitalized except for funny
words (like "VNC", "Props", "DBus") is not.  Need a list of funny words,
I guess.

Perhaps a single list of funnies would do for 1. and for 2.