Selon Florent JITIAUX <fjiti...@gmail.com>: > 2014-03-27 11:24 GMT+01:00 Even Rouault <even.roua...@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 _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
