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

[Momtchil Momtchev]

clang.jl is a very feature-light pybind11-style wrapper generator. It 
does not support C++, objects, inheritance, overloading, type 
downcasting and upcasting, iterators, n:m argument mapping, exceptions 
and many other advanced features. It even lacks interaction with the 
garbage collector relying on the user manually freeing the returned C 
data structures. All these features would require extensive manual 
wrapping work to implement. This is the major strength of SWIG - because 
you can implement those advanced features with minimal amount of work if 
you are willing to accept its very steep learning curve.

I don't use Julia, but I can still see that GDAL.jl is far below the 
level of the Python bindings which I know quite well. There is a higher 
level API built on top of it - ArchGDAL.jl - but it seems to be 
completely handwritten.


On 01/02/2025 23:45, Joaquim Manuel Freire Luís wrote:
>
>   * Surely the 100% handwritten bindings - such as PDAL for C# or GDAL
>     for Node.js or Julia
>
> Hi,
>
> Just a small clarification, the Julia bindings are a 100% automatic 
> creation and cost very little, when one knows how to do it.
>
> Joaquim
>
> *From:*gdal-dev <gdal-dev-bounces at lists.osgeo.org> *On Behalf Of 
> *Momtchil Momtchev via gdal-dev
> *Sent:* Saturday, February 1, 2025 10:09 PM
> *To:* gdal-dev at lists.osgeo.org
> *Subject:* Re: [gdal-dev] CSharp bindings queued for removal (was Re: 
> GDAL CSharp bindings maintainers/contributors listening... ?)
>
> On 31/01/2025 23:31, Howard Butler via gdal-dev wrote:
>
>     On Jan 31, 2025, at 8:18 AM, Even Rouault via gdal-dev
>     <gdal-dev at lists.osgeo.org> <mailto:gdal-dev at lists.osgeo.org> wrote:
>
>     My experience with GDAL informed what we did with PDAL. The first
>     thing was to not use SWIG. Lessons were learned, as they say :)
>     The approach of a single unified language binding generator was in
>     fashion in the 1990s at the same time as using UML to
>     automatically write software. History has shown both of these
>     things to have frustrating consequences.
>
> In 2025 SWIG still has no alternatives. It is surely dated and it may 
> be time to think about a successor project, but currently I am not 
> aware of anyone actually working on it.
>
> Recently there has been a new way to do it, pioneered by Boost and 
> made very popular by the pybind11 project. This same approach has been 
> copied by embind in emscripten/WASM and I also have my own nobind17 
> for Node.js. Even if these are much faster to learn and easier to 
> maintain - because they do not require a special and very awkward 
> specific language - everything is only C++ - they lack many of the 
> advanced features that allow a very large library such as GDAL to have 
> a fully native feel  - especially one that has not been designed from 
> scratch to be used from a higher-level language.
>
> Surely the 100% handwritten bindings - such as PDAL for C# or GDAL for 
> Node.js or Julia - have their advantages, but the development cost is 
> orders of magnitude higher. If I was to start GDAL for Node.js from 
> scratch, I was surely going to use SWIG. Both GDAL for Node.js and 
> GDAL for Julia use handwritten code because at the time of their 
> creation, SWIG did not have good support for those languages. PDAL's 
> API is orders of magnitude smaller than GDAL and it has been designed 
> to be used from a higher-level language.
>
> I personally think that the future belongs to a project that will use 
> the LLVM front-end and produce pybind11-like code, but this project 
> does not exist. NativeScript is going in this direction for 
> JavaScript, but they too, they lack many of the advanced SWIG features.
>
> Now, of course, if there is no one to work on GDAL for C#, there is 
> nothing to be done. It is unlikely there will ever be onboarding for 
> this, as its cost is far too great for something that probably will be 
> used only once. I am afraid that there are no real alternatives 
> besides SWIG.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20250202/cc232f1a/attachment.htm>