On 24/03/2014 21:46, Even Rouault wrote:
Hi,
"Release soon, release early", so for people who like UML diagrams (there is
also a prototype of C++ classes for those who don't like UML very much), here's
a blog entry with the outcome of my thoughts for a possible re-organisation of
the GDAL/OGR class hierarchy
http://erouault.blogspot.ca/2014/03/draft-gdalogr-class-hierarchy-for-gdal.html
I don't understand the need for HandleRasterData() and HandleVectorData().
Isn't inheriting from GDALEmptyRasterDataset or GDALEmptyVectorDataset
sufficient to convey the information that the class doesn't handle those
kind of datasets.
A call to GetLayerCount()/GetRasterCount() from the class user is
sufficient to say "no vector/raster data here", and a dynamic _cast to
GDALEmptyVectorDataset/GDALEmptyRasterDataset is even clearer to me, so
HandleRasterData()/HandleVectorData() would be a third way to tell the
same thing.
Also I'm not sure about the names GDALAbstract* since those are partial
implementations.
Comments, suggestions, ideas greatly welcome. It is really a challenge to revamp
the class hierarchy while avoiding to touch every existing driver in a
non-automated way.
Even
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
