diff options
| author | Volker Hilsheimer <volker.hilsheimer@qt.io> | 2022-09-15 17:50:25 +0200 |
|---|---|---|
| committer | Volker Hilsheimer <volker.hilsheimer@qt.io> | 2022-09-22 14:57:03 +0200 |
| commit | b6d24bad6ce6f52624467a4fe4043caee6e59ab4 (patch) | |
| tree | 25c074f37c186a3f6fe7adce4479c5f1b008647e /src/location/CMakeLists.txt | |
| parent | 30366d0850af1e5409d637652c53a8fab9a7ddc1 (diff) | |
| download | qtlocation-b6d24bad6ce6f52624467a4fe4043caee6e59ab4.tar.gz | |
Cleanup: QPlaceContent and subclasses (1/3)
QPlaceContent and subclasses are value types, and subclassing value
is a bad idea, for many reasons. Great care had been taken to work
around the slicing problem, resulting in lot of code and complexity.
Instead of the slicing problem, we now have the problem that we can
assign a QPlaceContent item to a QPlaceImage and back, but that same
QPlaceContent object can also be assigned to a QPlaceReview and a
QPlaceEditorial item. Those then end up as empty items. So while it
seems convenient to have C++ types, we replaced compile errors or
explicitly dynamic APIs, like QVariant, with implicit conversions that
require explicit type checks before, with the risk of silently losing
data.
Ironcially, applications access those different values then through
various QAbstractItemModel implementations - which return QVariants
anyway, requiring explicit type checking and coertion. And the C++
convenience is exclusively interesting for backend implementors, who
anyway need to parse data and identify types dynamically.
What we really need is a map of QVariants, and some information about
what kind of data we can get out of the map.
So as a first step in cleaning, replace the data storage with such a map
and remove all the subclass specific privates, together with all the
complexity (virtual functions, QSharedDataPointer::clone template
specializations, macros).
The subclasses themselves become very thin API wrappers. Their only
special feature is that they all can still be constructed from a
QPlaceContent instance. We need this for compatibility. With all the
convenience C++ APIs marked as deprecated, people can still use
those when using Qt 6.2-compatible Qt Location, and use the warnings
to prepare for Qt 6.5 where we can then remove those APIs entirely.
Change-Id: Id75f55d784fbe214a0db93d3c1f786209ef0a690
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
Diffstat (limited to 'src/location/CMakeLists.txt')
| -rw-r--r-- | src/location/CMakeLists.txt | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/src/location/CMakeLists.txt b/src/location/CMakeLists.txt index 072468f7..2cd289da 100644 --- a/src/location/CMakeLists.txt +++ b/src/location/CMakeLists.txt @@ -67,17 +67,17 @@ qt_internal_add_module(Location places/qplaceattribute_p.h places/qplacematchrequest.h places/qplacecontentreply.h places/qplacereview.h places/qplacecategory.h places/qplacesearchrequest.h - places/qplacecategory_p.h places/qplaceeditorial_p.h + places/qplacecategory_p.h places/qplaceproposedsearchresult.h places/qplacemanagerengine.h places/qplacecontentrequest.h places/qplacemanagerengine_p.h places/qplace.h places/qplacecontentrequest_p.h places/qplaceeditorial.h places/qplaceattribute.h - places/qplacedetailsreply.h places/qplaceimage_p.h + places/qplacedetailsreply.h places/qplaceratings_p.h places/unsupportedreplies_p.h places/qplacereply.h places/qplace_p.h places/qplaceresult_p.h places/qplacemanager.h places/qplacereply_p.h places/qplacesearchresult_p.h places/qplaceresult.h - places/qplacereview_p.h places/qplacematchreply.h + places/qplacematchreply.h places/qplacecontent.h places/qplacesearchreply.h places/qplacesupplier_p.h places/qplaceratings.h places/qplaceimage.h places/qplacesearchresult.h |