Marble/GeoData/PointerVsImplicitShare
Implicit sharing and storing objects as value is very reasonable for basic data as QStrings, but there are reasonable doubts regarding Placemarks and other GeoData. There are some possibilities:
- Don't use implicit sharing at all and store all objects on the heap with a pointer to it.
- Use implicit sharing and storing as value for GeoDataCoordinates only.
- Use implicit sharing and storing as value for all GeoData classes.
To find out which is the wisest I try to look at every single class: (please add your thoughts here)
Base data
- GeoDataCoordinates This one is quite simple. It is not more than a QPoint in GeoCoordinates. This should stay implicilty shared.
- GeoDataLatLonBox (GeoDataObject) It seems to nothing more than a QRect for GeoCoordinates. I'm not sure if it must be derived from GeoDataObject
- GeoDataLatLonAltBox same for this
- GeoDataAccuracy Should be base data => value
- GeoDataLod
- GeoDataRegion I'm not sure if it belongs into this group ...
Geometric structures
- GeoDataGeometry The base class for all geometric. We could want a pointer for this, so using it as data may not be the right way.
- GeoDataPoint This one uses multiple inheritance (GeoDataCoordinates). I don't think that this is semantically correct.
- GeoDataLineString
- GeoDataLinearRing
- GeoDataMultiGeometry
- GeoDataPolygon
Features
- GeoDataFeature These should be pointered, so GeoGraphicsItems could refer to them and change them easily.
- GeoDataFeature
- GeoDataContainer
- GeoDataFolder (by the way, this is an object which probably wouldn't need a GeoGraphics representation)
- GeoDataDocument (GeoDocument)
views
- GeoDataAbstractView It's nothing more than a view, this could stay implicitly shared.
- GeoDataLookAt Same for this as this is a child.
styles
- GeoDataColorStyle
- GeoDataIconStyle
- GeoDataLabelStyle
- GeoDataLineStyle
- GeoDataPolyStyle
- GeoDataStyleSelector
- GeoDataStyle
- GeoDataStyleMap (QMap<QString, QString>)
- GeoDataHotSpot
It is possible to group these things in two groups:
- objects that represent data which is actually shown on the map:
- Features
- objects that are abstract
- everything else :)
I'm not sure to which of the groups the geometry classes belongs.
A compromise could be to use the classes of the first group with a pointer and all others as a value. In KML all items are children of GeoDataObject (except GeoDataCoordinates). See here.