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

[Stefan Merettig]

Hi again, (sorry for the delays, my internet connection is really 
flaky)

I'd still hate to use QString::split(). But then I thought about your
suggestion to recycle the tag-column with a flag indicating the format
or something. As multiple Q_INFO annotations are allowed per 'object', 
we
need a sane approach for this anyway, and as you already stated, JSON 
would
be a valid option here.

So, first we store the data in a JSON structure:

   Q_INFO("foo", "bar")
   Q_INFO("qt", "five")
   MYTAG void method();
could be stored as:
   [{"foo": "bar", "qt": "five"}, "MYTAG"]

or similar. Doesn't really matter in the end anyway. What I ask myself 
now
is what should happen if the user uses a JSON structure as value. If 
it's a
list or object in the end doesn't matter, still, as we already use 
JSON,
we could do something like this in the QMetaInfo class:
     QByteArray name () const;
     QByteArray value () const // Returns the string value
     { return jsonValue().toString(); } /* Inlined as example */
     QJsonValue jsonValue() const; // Returns the JSON value in the 
object

That is, jsonValue() returns the JSON value in the Q_INFO object.
For what reason? moc could detect that the user used a JSON data 
himself
and then store it as real JSON data directly and not as a string.
Just a idea.

   Q_INFO("foo", "['bar', 'baz']") void method();

   -> [{"foo": ["bar", "baz"]}]
   vs
   -> [{"foo": "['bar', 'baz']"}]

I honestly don't see how that could be entirely wrong. The only ugly 
thing is
that moc needs to detect if the value is JSON data or not. What I like 
about
it is that it doesn't really introduce any complexity nor overhead, as 
we're
using JSON already in this case. The benefit to users isn't that huge 
anymore
though, as it'd shave off a bunch of source lines (to parse the data) 
on the
user-side, and save some cpu cycles.

Though I like the JSON approach in general.