[Development] [Feature] Q_INFO: Annotations for classes, methods, properties and enums

[Corentin Jabot]

>2013/9/11 Olivier Goffart <olivier at woboq.com>:
>> Alright guys, let's try to complete the feature. As I heard from sides
>> now that you want a key-value store, I'll do it that way.
>>
>> Feature list:
>> 1. Q_INFO is a new macro (which expands to nothing):
>>    #define Q_INFO(key, value)
>
> Since we have Q_CLASSINFO  for classes.
> maybe we should call it Q_METHODINFO and apply it only for method.

For the sake of clarity,  I think the number of keyword/terms should
be kept to a minimum.

Q_INFO(key, value) could be, for classes, a drop-in replacement for
Q_CLASSINFO(Key, value)
Q_CLASSINFO, could be somehow deprecated in a distant future and new
code advised to use Q_INFO instead.

methods would then also use Q_INFO

OR, Q_ANNOTATE, which sounds indeed better.

class, methods, enums and properties can have annotations.
That sounds simpler than having a specific mechanism for each object
type moc supports.


QMetaObject, QMetaProperty and QMetaMethods would have the following
new methods:

annotation()
annotationCount();
annotationOffset();
indexOfAnnotation()


QMetaObject would keep these methods as alias for compatibility purposes:

classInfo()
classInfoCount(),
classInfoOffset(),
indexOfClassInfo()

QMetaAnnotation could be an alias of QMetaClassInfo until 6.x

QMetaMethod::tag()  could be dropped in 6.x, tags being irrelevant when having
annotations, and the #define stuff was too hacky.





> Then, for Q_PROPERTY,  use a INFO as a keyword within the Q_PROPERTY syntax.
> I think it is easier to read.
> Let us compare again:
>
>  Q_INFO("foo", "bar")
>  Q_PROPERTY(int bar READ bar)
>  Q_INFO("foo", "baz")
>  Q_PROPERTY(int baz READ baz)
>
>
>  Q_PROPERTY(int bar READ bar INFO "foo" = "bar")
>  Q_PROPERTY(int baz READ baz INFO "foo" = "baz")
>
> You see the property name (more important) before the info. and everything is
> together.
>

It gets complicated if you want several annotations, and, it's not unified.
Again, an universal syntax for annotation is simpler than having a
syntax for class,
one for methods, and one for properties/enums

The "it's too verbose" argument makes little sense to me, I'd prefer
something a bit more verbose
but less confusing.

>
> Then for enums, we can have
>
> Q_ENUMS(MyEnum MyOtherEnum  INFO "foo" = "bar")
>

annotations for enums sounds overkill.

Q_ANNOTATE("foo", "bar")
Q_ENUMS(MyEnum)

In both case, it's sounds insane to allow annotation in a Q_ENUMS /
Q_FLAGS containing
several items



Corentin