[gdal-dev] Contour generation method in bindings

[Ari Jolma]

Tamas Szekeres kirjoitti:
> Ari, (and the other swiggers)
>
> I appreciate to add every new functionality in the SWIG bindings.
> However this change seems to be perl specific, and I don't know how is
> it planned to migrate the functionality to the common ground.
>   

Tamas,

It is not Perl-specific in any other way than being currently in 
gdal_perl.i. I'd like to see it go into gdal.i or , better, into 
Operations.i (which is included into gdal.i). I put it into gdal_perl.i 
only because it needs new typemaps and maybe some discussion before it 
goes into gdal.i. If I had put them into gdal.i without the necessary 
changes in typemaps of other languages, it would have broken them. Maybe 
this process: work through individual language .i files and once they 
are similarly in all, then migrate them into main .i files, could even 
be adopted as a preferred way to develop the bindings? I think we should 
also keep the main .i files as clean as possible from #ifdef language 
directives.

We are now doing the migration, I hope, but I'm not sure how much will 
go into 1.5 since the deadline is fast approaching.

> My other problem is that the layout of the codebase will be fairly
> chaotic in a little while. I personally don't favour blindly including
> many of the code between the interface files and manually excluding
> the name collisions. What if we will have to use GDALDriver an
> OGRDriver simultaneously in a function in the future?
>   

That would require a name change from Driver to GDALDriver and 
OGRDriver, I guess. It's a bit unfortunate that the original design did 
not consider this. In Perl space (and probably others too) the drivers 
are different Geo::GDAL::Driver and Geo::OGR::Driver, but in .i files 
they are both Driver.

I'm myself a bit of a organization and refactoring freak and would love 
to rethink and reorganize the *.i files. I hate the complexity that 
comes from adding new functionality into an architecture that was not 
designed with that functionality in mind. So I'm with you here but I 
also want to go on and add new things into the bindings.


> I would be in favour of refactoring the code using the following common rules:
>
> 1. Every target class would go into a separate interface file
> 2. Every interface file would be responsible to include the interface
> files that it depends on.
> 3. To avoid the name collisions we should either use namespaces (not
> sure how it is supported by the various target languages) or prefixes
> in the classnames
> 4. We should declare the constants in separate interface files that
> can be included by the others if needed.
>   

Looks good, can you illustrate this in practice, i.e., show the new .i 
files in include? If they compile with Swig and the Perl tests pass 
after the change, I'm for the refactoring.

> I agree that this concept would require  to change many of the files
> and would possibly bring in some backward incompatibility and would
> require some further investigations regarding to the feasibility and
> at least an RFC would be required and some support from the swiggers
> to tolerate and eliminate the breaking changes in the languages if
> any.
>   

If you can prepare an example, maybe in spike?, we could try and see 
what the implications and incompatibilities really are, then we could 
discuss in more concrete terms.

Best regards,

Ari