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

Stefan Merettig stefan-merettig at nuriaproject.org
Tue Sep 10 18:26:09 CEST 2013


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)
2. Q_INFO can be prepended to:
  - Classes
  - Signals, slots and Q_INVOKABLE methods (This includes c'tors)
  - Q_PROPERTY
  - Q_ENUM'd enums
  - So everything that is accessible through the meta system
3. Multiple Q_INFO annotations for a single object are possible
4. Each object has a unique key -> value mapping. This means, that 
something
    like: Q_INFO("a", "b") Q_INFO("a", "c") void myFunc(); results in a 
single
    key -> value mapping, not two values for "a".
5. API Design: Pretty much a copy of QMetaClassInfo from the user 
standpoint,
    the class will be called QMetaInfo.

Questions:
1. If Q_INFO can be applied to classes, then it's redundant to 
Q_CLASSINFO.
    On the one hand it's nice to have a unified API for annotations, on 
the
    other hand it's redundant, as Q_INFO doesn't have any benefits over
    Q_CLASSINFO anymore.
2. How should we store this? My current approach still stems from when 
Q_INFO
    supported multiple arguments. Technically possible, but not liked. 
As Thiago
    pointed out: JSON is out of the question. I'd like to stick to 
something like
    my current implementation. It boils down to having a table in the 
meta_data
    array with two columns for each object: start index, count
    At 'start index' there's a list of two integers for each Q_INFO 
record, the
    first pointing to the name, the second to the value. I'd like to use 
a third
    column there to store a currently unused "flag". In my initial 
implementation
    which is also on gerrit I have a fourth field to store the value 
count, but
    with only a single one this can obviously be dropped if we don't 
plan to ever
    support this feature.

Have a nice day,
Stefan Merettig



More information about the Development mailing list