[Gdal-dev] Some thoughts on C# SWIG wrapper

[Simon Perkins]

Richard Matsunaga wrote:
> Given that the bindings are still in an early state of development, 
> there is no time like the present to make breaking changes! It amounts 
> to minor changes to existing code in most cases.

It's a reasonable bet that most people using the SWIG C# bindings are on 
this list, so let's ask them! Anyone out there object to changing the C# 
API in a majorly breaking way?


> Along the same lines, the usual namespace convention is 
> CompanyName.Whatever. It would be much cleaner if the Gdal and Ogr 
> namespaces were under a common parent, such as Osgf or something 
> appropriate.

Personally I think GDAL (or Gdal) is a sufficiently unique namespace 
that there's not much to be gained by adding extra prefixes. But I don't 
have a strong preference.
 
> The fake enums you describe is what I had in mind and would make 
> things easier to manage. The only danger with using constants like 
> that is if the original value changes, the maintenance becomes a 
> nightmare.

Wouldn't newly compiled code just pick up the new values of the 
constants from the headers? Assuming people are not using numeric 
literals in their code. In any case I see zero chance of these values 
changing...

Cheers,

Sy

>  
> Richard
>
> ------------------------------------------------------------------------
> *From:* Simon Perkins [mailto:sy at perkins.net]
> *Sent:* March 2, 2007 4:50 PM
> *To:* Richard Matsunaga
> *Cc:* gdal-dev at lists.maptools.org
> *Subject:* Re: [Gdal-dev] Some thoughts on C# SWIG wrapper
>
> Richard Matsunaga wrote:
>> I've just started using the C# bindings and have some questions.
>>  
>> 1. Is the casing used in the bindings a by-product of SWIG, or can 
>> this be changed to follow the usual conventions? e.g. the 'gdal' 
>> class, the 'GDAL' namespace, the use of underscores
>
> This would be nice, but I suspect that there are a number of people 
> out there using the existing bindings who might object to having to 
> change their code. Standard usage would have called the GDAL namespace 
> "Gdal", and the gdal class "Gdal" as well (I think this would work), 
> but I can live with this quirk.
>
>>  
>> 2. Is it possible to make enums out of the constants (since the 
>> values are dynamically generated, even separate classes would be 
>> better), so they have some useful context? It makes it much harder 
>> for non GDAL/OGR experts to find the correct values.
>
> This would also be nice, but again we have the backwards compatibility 
> issue. We could keep the GDAL.gdalconst class, but add the enums into 
> the GDAL namespace, but then the GDAL functions that currently expect 
> ints would either have to be duplicated for enum versions, or we'd 
> break code.
>
> One option would be to fake the enums with classes like:
>
> namespace GDAL
> {
>     public class DataType
>     {
>        public static const int Byte = 0;
>        public static const int Int16 = 1;
>        ...
>     }
> }
>
> We could add these classes in addition to GDAL.gdalconst and allow 
> people to use them interchangeably.
>
> Tamas: what do you think?
>
> Cheers,
>
> Sy
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20070302/1863106b/attachment.html