[Kde-pim] Polymorphic Payload Support for Akonadi::Item

[Volker Krause]

Hi,

with email notifications for reviewboard still broken I have to do that 
myself, please see http://reviewboard.kde.org/r/626/ :)

It affects not only Akonadi but also various other libs in kdepimlibs, namely 
KCal, KMime and KPIMUtils.

Description:

Polymorphic payload support means that the payload mechanism in Akonadi::Item 
is no longer limited to retrieve the exact same payload type that was put in, 
but can now also cast if possible, which is especially useful with payloads 
like KCal or KMime objects.

However, implementing that is much harder than it sounds and requires some 
external hints, namely compile-time introspection of the inheritance 
hierarchy (even Marc didn't find a way around that). This is provided by 
KPIMUtils::SuperTrait and its specializations in KCal and KMime. This is pure 
template stuff, so no effects on the ABI. As it is needed by Akonadi, KCal 
and KMime, kpimutils was unfortunately the only possible location, apart from 
a new top-level directory.

While I was at it I also added convenience typedefs for shared pointers for 
KCal and KMime objects, as we have them all over Akonadi code currently. They 
only use forward declarations, so no there is no new boost dependency for 
those libraries.

The changes to Akonadi::Item itself have a few side-effects though, besides 
adding support for polymorphic payloads in boost::shared_ptr and 
QSharedPointer:
- There are strict compile-time checks for invalid payload types now, so 
trying to use a pointer as payload will fail to compile instead of crash at 
runtime now.
- When using a shared pointer payload, the class the shared pointer contains 
now needs to be fully declared when the payload related templates are 
instantiated, so far one could get away with just a forward declaration in 
some cases. I only found one occurence of that in our code, so this doesn't 
seem to be a problem in practice.
- So far behaviour was pretty much undefined when retrieving a mismatching 
payload type (most probably it would crash somehow), in this cases an 
exception is thrown now. This will reliably crash if the application doesn't 
care (normal code should use hasPayload() and never get there), but also 
allows handling this kind of error (which eg. the Item code uses internally). 
This however has one big downside: we need to compile every user of the 
payload mechanism with exception support now (the exception throwing happens 
in template code). One could argue this is a SIC change, in fact multiple 
applications in kdepim needed ${KDE4_ENABLE_EXCEPTIONS} added in their cmake 
files.


regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20090424/4665e366/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/