D13104: Protocol: QJsonObject for tracer.

[Sandro Knauß]

knauss added inline comments.

INLINE COMMENTS

> dvratil wrote in protocol.cpp:207
> Instead of manually chaining up like this (you are missing chain-up from `ChangeNotification` to `Command` btw), you could add this to the beginning of the generated `toJson` method:
> 
>   if (!parentClass.isEmpty()) {
>       mImpl << "    " << parentClass << "::toJson(json);\n";
>   }
> 
> Then you won't need all the special cases and it will work generically for any level of inheritance.

this does not work, as the method is not virtual, so in the end we have a CommandPtr in Akonadi::Server::Connection so than we need a logic to static_cast this to the real class. With parent::toJson we end up currently in an endless loop as we satrt in the base class Command::toJson.

> dvratil wrote in protocol_p.h:158
> Hmm, technically this should be `virtual`, shouldn't it? But I don't want to introduce virtual methods into Protocol objects, that's why the debugString() is done in that slightly cumbersome way of having Protocol::debugString() which calls the free `QDebug operator<<(QDebug &, ....)` functions. Maybe we could have the same for JSON, just have a free `QJsonObject &operator<<(QJsonObject &obj, ....)` free function for each Protocol class and make it a friend, so it can access its members and introduce Protocol::debugJson() method that calls the respective operator as well. What do you think?

what is the advantage of a free operator? as the operator do not match as OJsonObject is a map like object.

REPOSITORY
  R165 Akonadi

REVISION DETAIL
  https://phabricator.kde.org/D13104

To: knauss, dvratil
Cc: kde-pim, dvasin, rodsevich, winterz, vkrause, mlaurent, knauss, dvratil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20180528/f3c3d226/attachment.html>