D5667: delay filtering to the point when a new item gets its remote id

[Martin Koller]

mkoller added inline comments.

INLINE COMMENTS

> dvratil wrote in mailfilteragent.cpp:129
> There's also a non-const Monitor::itemFetchScope() overload that returns a non-const reference, so you can do
> 
>   itemMonitor->itemFetchScope().setFetchRemoteIdentification(true)
> 
> Not a big issue, you can fix it before committing if you want to.

It's your code, so I follow your rules.
However from an OO point of view, I do not like classes which return non-const refs to members.
That's changing things behind the back of the owner class.
In that case the member could also just be public, which also circumvents the OO mechanism.

Please tell me if I shall do it like you proposed or if I shall commit as is.

REPOSITORY
  R206 KMail

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

To: mkoller, dvratil, mlaurent
Cc: knauss, #kde_pim, dvasin, ach, winterz, vkrause, mlaurent, dvratil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20170503/da915a7d/attachment.html>