On Wed, 14 Aug 2019 11:39:32 +0200
Sebastiaan Couwenberg <sebas...@xs4all.nl> wrote:

> > The bindings are done 
> > for C++ geos interface, and mostly maches 1 to 1, when it is possible to 
> > keep API "perlish",
> > i.e. not to crash due to dangling reference.  
> .
> Why not the stable C API?
> The bindings are likely to break every time GEOS is updated. They will
> at least need to be rebuilt when GEOS is updated to link to the new library.

It was internal decision to use C++ API instead of C. Among the reasons:

- library distribution model: it was decided to let the libgeos be shipped 
via cpan.org rather then rely on system library & their maintainers [1]. 
That's way it is a little bit controlled from our side and we less dependent
on system maintainers (e.g. see report matrix availablity [2])

- It is trivial to write Perl(XS) adapters for C++ interface, rather than
for C, as we are using XS::Framework [3]. For example, for perl code

my $exterior_ring = $polygon->getExteriorRing()

the binding will be 3-line code (XS)

LinearRing* geos::geom::Polygon::getExteriorRing() {
    RETVAL = dyn_cast<LinearRing*>(THIS->getExteriorRing()->clone());

(See full samples at [4])

- We don't wanted to loose performance having additional stability layer.

So, yes, with new Geos version we have to bump new bindings release. When 
we used the library internally, and the new 3.7.0 was released, the
transition 3.6.2 => 3.7.0 was almost trivial (less then one hour). 

[1] https://metacpan.org/pod/CPP::geos 
[2] http://matrix.cpantesters.org/?dist=CPP-geos+
[3] https://metacpan.org/pod/XS::Framework
[4] https://metacpan.org/source/DMOL/Geo-Geos-1.0.1/xsi

WBR, Ivan Baidakou
geos-devel mailing list

Reply via email to