[Gdal-dev] Some thoughts on C# SWIG wrapper
szekerest at gmail.com
Fri Mar 2 18:16:05 EST 2007
2007/3/2, Richard Matsunaga <richard.matsunaga at waypointinfo.com>:
> 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
Renaming the namespaces would not be a problem, it's controlled by the
makefile.vc as a SWIG commandline option. Altering the module name is
also possible. It would bring in some divergence from the other
bindings but this kind of renaming has already been done by PERL for
example. In gdal.i we already have
However altering the names derived from the gdal core (like function
or parameter names) would not easily be supportable.
At this point I cannot see a real benefit altering the names from the
point of view of the proper operation of the interface. However I have
no objection changing the namespace and module names if most of the
folks cannot really tolerate as it stands. I consider adding the same
name for the namespace and the module would be confusing. Any ideas?
> 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.
No problem about wrapping the various enums for the C# API. Following
the current implementations some kind of C# specific additions should
be done and the backward compatibility cannot be retained. I consider
the object members using these types should also be altered to the
corresponding C# enum type, like 'public int DataType' would be
changed to 'public GDALDataType DataType' for the Band class for
I will make an attempt to do something usable this weekend or so.
> 3. Might be worth running the assemblies through FxCop to find egregious
> violations of standards.
Indeed. But many of the complaints cannot be handled easily.
More information about the Gdal-dev