Marble/GeoData/PointerVsImplicitShare: Difference between revisions

From KDE TechBase
No edit summary
No edit summary
Line 6: Line 6:


To find out which is the wisest I try to look at every single class:
To find out which is the wisest I try to look at every single class:
(please add your thoughts here)
=== Others ===
* '''GeoDataHotSpot''' This doesn't use Geo coordinates. I'm not sure if this really is GeoData, at all (I have not checked for what it is used).


=== Base data ===
=== Base data ===
Line 11: Line 15:
* '''GeoDataLatLonBox''' (GeoDataObject) It seems to nothing more than a QRect for GeoCoordinates. I'm not sure if it must be derived from GeoDataObject
* '''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
** '''GeoDataLatLonAltBox''' same for this
* '''GeoDataAccuracy''' Should be base data => value
* '''GeoDataLod'''
* '''GeoDataRegion''' I'm not sure if it belongs into this group ...


=== Geometric structures ===
=== 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.
* '''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.
** '''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 ===
=== views ===
* '''GeoDataAbstractView''' It's nothing more than a view, this could stay implicitly shared.
* '''GeoDataAbstractView''' It's nothing more than a view, this could stay implicitly shared.
** '''GeoDataLookAt''' Same for this as this is a child.
** '''GeoDataLookAt''' Same for this as this is a child.
=== styles ===
* '''GeoDataColorStyle'''
** '''GeoDataIconStyle'''
** '''GeoDataLabelStyle'''
** '''GeoDataLineStyle'''
** '''GeoDataPolyStyle'''
* '''GeoDataStyleSelector'''
** '''GeoDataStyle'''
** '''GeoDataStyleMap''' (QMap<QString, QString>)
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.

Revision as of 14:12, 31 March 2010

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)

Others

  • GeoDataHotSpot This doesn't use Geo coordinates. I'm not sure if this really is GeoData, at all (I have not checked for what it is used).

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>)

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.

Retrieved from "https://techbase.kde.org/index.php?title=Marble/GeoData/PointerVsImplicitShare&oldid=50441"