<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2014-03-27 11:24 GMT+01:00 Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@mines-paris.org" target="_blank">even.rouault@mines-paris.org</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<div class=""><br>
> Hi all,<br>
><br>
> MY opinion is that's not a really good way to count how many classes you<br>
> will have and trying to have minimal classes.<br>
><br>
> Drawing a model with UML is not easy : it's not easy to have a good model<br>
> from the beginning, it's not easy to name all members and methods<br>
> correctly, and the worst is inheritance.<br>
> You can think you spend too much time to make the model. But you can't say<br>
> if you will spend less or much time to change code because your model was<br>
> too simple.<br>
<br>
</div>The issue is that I'm trying to "refactor" a code base of 1.2 million lines of<br>
C/C++ code (not mentionning the 140 000 lines of Python tests), and with 211<br>
existing drivers. So, given that nobody will probably ever want to fund the<br>
effort, it is completely excluded to have to edit each of those drivers in a non<br>
automated way...<br>
The end solution will necessary be a compromise. I would also like the existing<br>
C API to continue working as much as possible.<br>
<div class=""><br></div></blockquote><div>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.<br></div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
><br>
> Because I don't know all the model of Gdal and the model can be "reset" I<br>
> have some questions :<br>
><br>
> 1) Why GDALMajorObject not inherit of GDALIMajorObject ?<br>
<br>
</div>It was just an omission in the UML diagram. My C++ sketch had this inheritance.<br>
<div class=""><br>
><br>
> 2) Why all classes inherit (directly or not) of GDALMajorObject ?<br>
<br>
</div>That's how it is done currently.<br>
<div class=""><br>
> What do<br>
> you store in it ?<br>
<br>
</div>It contains a list of list of strings, or in more concrete terms, metadata<br>
domains that contain metadata items.<br>
<div class=""><br>
> Is it possible to put it as a member in classes ?<br>
<br>
</div>That could have been a way of doing it, yes. Always the debate composition vs<br>
inheritance.<br>
<div class=""><br></div></blockquote><div>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.<br>
<br></div><div>I know it's not important for a lot of people but I like when a model is precise. At the beginning, you could only draw interfaces to define what classes and subclasses are.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">
> Have<br>
> you consider templates ?<br>
<br>
</div>Actually, no. I tend to avoid them unless they are an obvious solution.<br>
<div class=""><br>
><br>
> 3) An interface for Drivers ? geName(), getLongName(), getDescription() ?<br>
> Or maybe abstract ...<br>
><br>
> 4) What is GDALDataset in your diagram ?<br>
<br>
</div>It is the base class that a driver that supports both raster and vector would<br>
have to subclass.<br></blockquote><div><br></div><div>I think I missed something : today is there a driver which support both ?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=""><br>
><br>
> 5) Where is the link between Driver (Gdal/Ogr) and Dataset (Raster/Vector)<br>
> ? Member, templates ?<br>
<br>
</div>A Driver instanciates a Dataset by opening an existing one, or by creating a new<br>
one. But the Dataset object itself is a free-standing objects that is only owned<br>
by user code, and not by the Driver.<br>
<br>
For now, I've dropped my crazy UML diagram that nobody would be able to<br>
understand, even if I managed to make it work, and I'm pursuing my attempt<br>
just merging OGRDataSource inside GDALDataset. And make OGRDriver and<br>
OGRSFDriverRegistrar mostly disappear, or just create a minimized version of<br>
them, as compatibility layer for existing drivers, that forward the real work to<br>
GDALDriver and GDALDriverManager.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div>Your diagram is understandable. This is just because everyone has his own representation of a model and it is important (for me) to understand why your model is like that. With good arguments people can agrees.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
Even</font></span><br></blockquote></div><br></div><div class="gmail_extra">Florent<br></div></div>