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

[Olivier Goffart]

Hi,

Great to see we are making progress.

On Tuesday 10 September 2013 18:26:09 Stefan Merettig wrote:
> 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.

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.


Then for enums, we can have 

Q_ENUMS(MyEnum MyOtherEnum  INFO "foo" = "bar")

That would only be a problem if there is an enum called "INFO", but i think we 
are safe,  it is not the Qt style.

Then we have everything, with nice syntax.

> 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

I beleive that Thiago meant that JSON was out of question for describing the 
properties in the actual source.  
But i would not necessarily rule it out for storing the data. moc already 
export some data using Qt's binary JSON, so this is still a valid option.

That said, I think that having the info stored in the meta_data table, like 
Q_CLASSINFO is, is just fine.


>     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.


-- 
Olivier

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org