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

[Simon Perkins]

Tamas Szekeres wrote:
> 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?

I don't have any real objections to changing things, and if other people 
don't mind changing their code, then now is probably the time to do it. 
So maybe we should go the whole way and put everything in the Osgf.Gdal 
namespace, and implement the enums as proper enums. Note that the 
standard .NET way of rendering acronyms in Studly Caps is to only 
capitalize the first letter.

I don't personally object to keeping the static methods in a Gdal class 
within that namespace either - there's precedent for it. But if we don't 
want that, how about calling the class Util, or Core, or Misc or 
something, so you'd write:

using Osgf;

Gdal.Dataset dataset = Gdal.Util.Open("foo.tiff");

Any of those names is fine with me. Let's keep it short though!

Sy


>
>
>> 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
> example.
> 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.
>
>
> Best regards,
>
> Tamas
> _______________________________________________
> Gdal-dev mailing list
> Gdal-dev at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/gdal-dev