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

[Even Rouault]

Selon Florent JITIAUX <fjitiaux at gmail.com>:

> 2014-03-27 11:24 GMT+01:00 Even Rouault <even.rouault at mines-paris.org>:
>
> > Hi,
> >
> > > Hi all,
> > >
> > > MY opinion is that's not a really good way to count how many classes you
> > > will have and trying to have minimal classes.
> > >
> > > Drawing a model with UML is not easy : it's not easy to have a good model
> > > from the beginning, it's not easy to name all members and methods
> > > correctly, and the worst is inheritance.
> > > You can think you spend too much time to make the model. But you can't
> > say
> > > if you will spend less or much time to change code because your model was
> > > too simple.
> >
> > The issue is that I'm trying to "refactor" a code base of 1.2 million
> > lines of
> > C/C++ code (not mentionning the 140 000 lines of Python tests), and with
> > 211
> > existing drivers. So, given that nobody will probably ever want to fund the
> > effort, it is completely excluded to have to edit each of those drivers in
> > a non
> > automated way...
> > The end solution will necessary be a compromise. I would also like the
> > existing
> > C API to continue working as much as possible.
> >
> > That was not a reproach because I know refactoring may be very difficult
> and it's takes so much time. But that's why making a model which can evolve
> is important.
>
>
> > >
> > > Because I don't know all the model of Gdal and the model can be "reset" I
> > > have some questions :
> > >
> > > 1) Why GDALMajorObject not inherit of GDALIMajorObject ?
> >
> > It was just an omission in the UML diagram. My C++ sketch had this
> > inheritance.
> >
> > >
> > > 2) Why all classes inherit (directly or not) of GDALMajorObject ?
> >
> > That's how it is done currently.
> >
> > > What do
> > > you store in it ?
> >
> > It contains a list of list of strings, or in more concrete terms, metadata
> > domains that contain metadata items.
> >
> > > Is it possible to put it as a member in classes ?
> >
> > That could have been a way of doing it, yes. Always the debate composition
> > vs
> > inheritance.
> >
> > The question is : classes (Raster, Driver, ...) are a GDALMajorObject or
> classes have a GDALMajorObject ? If it's just a list (map with key/value ?)
> of String, I'm not sure it defines what subclasses are.

Actually, my explanation was a bit simplified. A GDALMajorObject has a
GDALMultiDomainMetadata member, and that one is a list of list of strings that
have the key=value syntax. Could be more sophisticated. But that's an
implementation detail.
And I guess the reason that classes extend GDALMajorObject rather than have a
GDALMajorObject object was to save line of codes that are needed when you use
composition instead of inheritance (
http://en.wikipedia.org/wiki/Composition_over_inheritance )
I'm just explaining the current state of things in the GDAL world, and I didn't
really plan to change that.

> I think I missed something : today is there a driver which support both ?

Well, no. That's actually the reason for that temptative work. It is not
possible currently to have a raster+vector driver. For data containers that
support both, you have to implement currently both a GDAL driver and a OGR
driver. But for example you cannot safely open the GDAL dataset and OGR
datasource in update mode.

Even