Am Dienstag, den 01.11.2011, 14:05 +0100 schrieb Mathias Hasselmann: > Am Dienstag, den 01.11.2011, 09:56 +0100 schrieb Robin Burchell: > > Hi Paivi, > > > > > Another step towards that direction would be to hide the internal format > > > of > > > backend contact id by providing a wrapper class for backend ids. This > > > pattern > > > has been used in Organizer, see > > > http://qt.gitorious.org/qt/qtpim/blobs/master/src/organizer/qorganizeritemengineid.h > > > and > > > http://qt.gitorious.org/qt/qtpim/blobs/master/src/organizer/qorganizeritemid.h. > > > > This might make sense. Just keep memory constraints in mind. I don't > > know about typical organizer patterns, but often, applications dealing > > with contacts are forced (for various reasons, efficiency, etc) to > > keep a memory representation of a large number of contacts in memory. > > If you're heap allocating IDs (as well as all their details etc) - > > that's another penalty you're going to pay in terms of performance. > > Probably not *that* huge a concern, just make sure to measure first. > > :) > > Cannot you explain the idea behind this? I cannot follow right now. >
Short IRC discussion with Robin revealed the idea to me. You want permit the backend itself define what a local id looks like. So you propose an even more sophisticated variant of my QVariant propose. Also fine with me. Hard part will be defining a proper API that avoids accidential round trips between native format and string (or QVariant) representation. Also the documenation of such a class should be very explicit about memory consumption, performance and such. Maybe even a few default implementations demonstrating best practice should be provided. Ciao, Mathias -- Mathias Hasselmann <[email protected]> http://openismus.com/ _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
