[gdal-dev] CSharp bindings queued for removal (was Re: GDAL CSharp bindings maintainers/contributors listening... ?)

[Even Rouault]

Le 31/01/2025 à 13:09, Paul Harwood a écrit :
> The problem about "moving" the bindings is going to be that all of the 
> SWIG definitions for all bindings are intimately wound together. It 
> would be a lot of work for little gain.

That intertwine is both a strength and a weakness of our bindings, in 
that it apparently minimizes the level of effort to have them, but it 
results in bindings that are neither Pythonic, Javaish (or C#'ish  ? no 
idea about how C# users feel about the GDAL ones), and that nobody 
really feels responsible about. The obvious illustration is that the 
casing convention one uses in the .i files for method and parameter 
names influences *all* bindings and obviously you can't expect all 
languages to agree on CamelCase, camelCase or snake_case ... Not to 
mention that in lots of case we just copy&paste the Hungarian convention 
from the C API that even most C users would dislike.

I know Howard has been a long time advocate of kicking all bindings out 
of OSGeo/GDAL and let them flourish or perish in their standalone 
existence (we just chatted yesterday about that again), and he's pretty 
happy with how that turned out for PDAL. But I'm also not so convinced 
that the return on investment is high enough for GDAL (contrary to the 
switch to CMake where there was a significant initial cost but I was 
convinced that it would be a big win, which it is), especially when 
selfishly thinking to the Python bindings, especially given their 
central place in libgdal testing.

>
> NONE of these possibilities would be a valid response to our lack of 
> knowledge.

You're right. I saw recently a toot from another OSS maintainer who also 
complained he had little clue about which part of his software were 
used, except when people filed bugs.

Options (readers: don't read all of them too literally and scream, just 
my current brain dump...):

- add on purpose bugs to the software to know which parts are used (at 
least the parts where you don't know) ?

- do nothing and let people feel demotivated/frustrated about 
maintaining the software and give up ?   Only people who don't maintain 
code could naively assume there is a zero cost in keeping unused code 
around. The cost is hard to objectivize, but it is definitely not zero. 
If we had to pay for the VMs of our CI, there would be a clear cost in 
$$ for that.  It also costs in term of time for maintainers when they 
develop and have to wait for a build to complete. Or when Coverity Scan, 
cppcheck, etc. have an upgrade in their analyzers that suddenly raise a 
new category of warnings. This is a sum of little something.

- wait that AI finally kick out human maintainers from the equation and 
can deal with an ever growing code base without complaining ?

- less provocative: add telemetry. obviously not opt-in because nobody 
would take the time to turn it on, but just opt-out

Even

-- 

http://www.spatialys.com
My software is free, but my time generally not.
Grumpy maintainer.
"De l'égo à l'égoût, il n'y a qu'une bouche mal refermée", André Isaac