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

[Even Rouault]

Selon Vincent Mora <vincent.mora at oslandia.com>:

> On 25/03/2014 11:44, Even Rouault wrote:
> > Selon Vincent Mora <vincent.mora at oslandia.com>:
> >
> >> 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.
> > Actually, when thinking more about this, this kind of information should be
> at
> > the driver level, and not at the dataset level. The idea is that there are
> use
> > cases where you want to know if a driver can handle only vector, only
> raster, or
> > both. For example if you still want to have separate Open dialog boxes for
> > raster or vector.
> >> Also I'm not sure about the names GDALAbstract* since those are partial
> >> implementations.
> > I know I'm not very good at naming. Do you have an alternative proposal ?
> The
> > issue is that with my draft we end up with a lot of classes and interfaces,
> so
> > it is not obvious to find a good name to reflect their content.
> Partial sound ok to me, but I not so good at naming  ?
>
> Considering the number of classes, I gave it some thoughts this morning
> and, like Dmitry, thought of merging the Abtract (Partial) into the
> interface before realizing that, even if it works (you can overload de
> default function in Empty) it's a bit ugly and I ended up preferring
> your solution.
>
> An altenative would be to have a Dataset with both aspects and provide
> three partial specialisations: one for vector (it will behave like empty
> raster) one for raster, and one for both. Code duplications could be
> avoided by implementing protected member functions in the Dataset class
> and simply calling them in the implementations of partial
> specialization. This solution avoid the diamond shaped inheritance
> diagram of hell :)

Actually the diamond shaped inheritance does not work at all (as I somehow
feared ;-)). I must have confused myself with how I would have done things in
Java, but in C++, I can't manage to do it... Here's a self-contained code that
does not compile : https://gist.github.com/rouault/9761494

I think I'm going to try something more plain and stupid. Just "import" methods
from OGRDataSource into GDALDataset, making OGRDataSource extends GDALDataset
and make that compile...

I'm not sure to have understood what you meant with "protected member functions
in the Dataset class and simply calling them in the implementations of partial
specialization". With an example it would be clearer to me.

>
> >
> > Even
> >
> >
>
>