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

Simon Perkins sy at perkins.net
Fri Mar 2 17:40:21 EST 2007

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 



> 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

More information about the Gdal-dev mailing list