[Gdal-dev] Some thoughts on C# SWIG wrapper
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
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
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
> *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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gdal-dev