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

Matt Broadstone mbroadst at gmail.com
Wed Sep 11 18:03:52 CEST 2013


On Wed, Sep 11, 2013 at 2:33 AM, Olivier Goffart <olivier at woboq.com> wrote:

> 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")
>
>
I think this is too verbose. If we're already headed towards java-style
annotations why not just have an annotate that can align with a Q_PROPERTY:

Q_PROPERTY(int bar READ bar WRITE setBar)
(this gives us a good, clear definition of the property)

Q_ANNOTATE(bar, foo = "baz", abc  = "cde")
(this annotates the aforementioned property, and is a specialization of the
"normal" Q_ANNOTATE, and can appear anywhere in the class definition)

Matt



> 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
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130911/f6541148/attachment.html>


More information about the Development mailing list