On terça-feira, 10 de setembro de 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) > 2. Q_INFO can be prepended to: > - Classes
We have Q_CLASSINFO for that.
> - Signals, slots and Q_INVOKABLE methods (This includes c'tors)
> - Q_PROPERTY
Other people have suggested adding the info to the Q_PROPERTY expansion. This
would avoid a sequence of Q_INFO / Q_PROPERTY pairs in the class that might be
difficult to read:
Q_INFO("foo", "bar")
Q_PROPERTY(int bar READ bar)
Q_INFO("foo", "baz")
Q_PROPERTY(int baz READ baz)
> - 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".
Why?
> 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.
I prefer Q_CLASSINFO.
> 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.
Keeping an unused "flag" field is a good idea.
How do you associate the method ID or property ID with an info?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
