Eric Blake <ebl...@redhat.com> writes:
> On 03/10/2016 06:39 AM, Markus Armbruster wrote:
>> Eric Blake <ebl...@redhat.com> writes:
>>
>>> The original choice of ':obj-' as the prefix for implicit types
>>> made it obvious that we weren't going to clash with any user-defined
>>> names. But now we want to create structs for implicit types.
>>
>> Why? I know, but the commit message should still give a hint. Perhaps:
>> "to get rid of special cases in the generators"?
>>
>>> We
>>> could transliterate ':' to '_', except that C99 says that a leading
>>> underscore and lower-case letter should be used only for file scope
>>> identifiers, while we would be exposing it in qapi-types.h. So it's
>>
>> Misunderstanding! When the standard says "identifiers that X are
>> reserved for Y use", it reserves these identifiers for itself and the
>> implementation. You shouldn't use them for Y then.
>>
>> Suggest to simply quote the standard instead of interpreting it:
>> ... except that C99 mandates that "identifiers that begin with an
>> underscore are always reserved for use as identifiers with file scope in
>> both the ordinary and tag name spaces"
>
> Both those changes sound fine.
>
>>
>>> time to change our naming convention; we can instead use the 'q_'
>>> prefix that we reserved for ourselves back in commit 9fb081e0. As
>>> long as we don't declare 'empty' or 'obj' ticklish, it shouldn't
>>> clash with c_name() prepending 'q_' to the user's ticklish names.
>>
>> Do we really want to rename :empty? We're not going to generate C for
>> it, are we?
>
> No, but it was easier to implement .is_implicit() as
> "name.startswith('q_')" than as "name == ':empty' or
> name.startswith('q_obj')". I can stick with :empty if you want a
> respin, though.
You avoid complicating .is_implicit() slightly, and you pay for that
with a bit of patch churn elsewhere. Sounds justified.
Is ':empty' the last use of the ':' prefix?
General maxims:
1. Keep the generator simple while generating something reasonable. No
need to overcomplicate things when we can rely on the optimizer to do
its job. Keeping headers lean is worth more complexity than keeping .c
files lean, because headers get compiled much, much more.
2. When all else is equal, avoid patch churn.
