[gdal-dev] Draft GDAL/OGR class hierarchy for GDAL 2.0

[Vincent Mora]

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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev