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

[Dmitriy Baryshnikov]

According to naming conventions I think, that pure interface classes 
should start with I (e.g. IGDALRasterDataset, IGDALVectorDataset).
For the Abstract class maybe such naming will sute:
GDALEmptyRasterDataset -> GDALRasterDataset
GDALAbstractRasterDataset -> GDALRasterDatasetBase
GDALIRasterDataset -> IGDALRasterDataset

Best regards,
     Dmitry

25.03.2014 16:13, Vincent Mora пишет:
> 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 :)
>
>> Even
>>
>>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>