[Development] Keep dependent projects in mind when approving changes
paivi.rajala at nokia.com
paivi.rajala at nokia.com
Thu Oct 27 17:08:32 CEST 2011
We thought that having an integer QContactLocalId is a bit too restricting. E.g. if you have a uuid as backend contact id (as the case is in JsonDb backend), it's lot simpler to treat it as a string than as an integer. Changing QContactLocalId to QString was the first step in trying to make contact ids a bit more flexible.
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. Any other ideas about how to make handling of backend contact ids both flexible and efficient are welcome.
About source-compatibility... As a Qt5 AddOn module QtPim has little less restrictions regarding source-compatibility than Essential modules, see e.g. http://developer.qt.nokia.com/groups/qt_contributors_summit/wiki/Qt5ProductDefinition. While we try not to break source-compatibility if it's not necessary, we also see moving from QtMobility to QtPim as a good opportunity to simplify QtPim APIs a bit and to make some other changes, which might be more difficult later. Some of the changes are already visible in qtpim repository, some are still in the planning phase. We will tell more about the changes and reasoning behind them in the near future.
From: development-bounces+paivi.rajala=nokia.com at qt-project.org [mailto:development-bounces+paivi.rajala=nokia.com at qt-project.org] On Behalf Of ext Robin Burchell
Sent: 27. lokakuuta 2011 10:18
To: Knoll Lars (Nokia-MP-Qt/Oslo)
Cc: development at qt-project.org
Subject: Re: [Development] Keep dependent projects in mind when approving changes
On Thu, Oct 27, 2011 at 8:21 AM, <lars.knoll at nokia.com> wrote:
> In addition, I'd like to be added as a reviewer for changes that break
> source compatibility with the public API of Qt 4.x. Please also add
> some comment in the changes file in this case.
Following up on this, do you have any information about this source-incompatible change:
Other reasons why I'd like this change justified:
- It's also going to be a lot less efficient to have a QContactLocalId as a QHash key in Qt5
- QString keys are naturally less memory-efficient.
Development mailing list
Development at qt-project.org
More information about the Development