[geos-devel] RFC 9: Restore C++ API as public API

[lnkansa]

NON PSC:
While I do appreciate the work of the library developers, I do support that
fact that C++ API is made available for the larger community. C++ is
enjoying Renaissance (11, 14, 17, 20) and attempts to "force" downstream
developers to use the the C-API rather decreases programmer productivity. A
good example would be the use of unique_ptr for resource management - it is
as good as it gets. Why not just use it as it is intended? After all, there
are always a thousand ways to compile a library with different compiler
switches. That is a beauty and also a pain - This is what partly defines
our DNA. Stable projects would always use CAPI knowing the consequences.
Anyone who opens up the hood should know what he is doing and if the person
shoots himself in the foot so be it. Those using C++ would have to compile
anyway. OSS projects that take such dependencies are the ones that should
pay the price and not the other way around. If their usage breaks your
packaged distro, they should pay the price of being dropped. After all
engineering is about choices. Please bring the C++ API back a first class
citizen.

On Fri, May 17, 2019 at 4:53 PM Sebastiaan Couwenberg <sebastic at xs4all.nl>
wrote:

> On 5/17/19 4:43 PM, Mateusz Loskot wrote:
> > On Fri, 17 May 2019 at 08:36, Sebastiaan Couwenberg <sebastic at xs4all.nl>
> wrote:
> >> On 5/17/19 3:23 PM, Andrew Bell wrote:
> >>> Frequent, breaking API changes seem a problem. ABI changes seem more
> like a
> >>> small annoyance. I can understand how a stable ABI would be nice, but I
> >>> personally don't think it's more important than a good interface for
> >>> library users.
> >>
> >> And that's the difference in perspective between a developer and
> >> distribution packager.
> >
> > It is not my role of a library developer to make packaging easier.
> > There are many PMs and PDMs, OS-specific, distro-specific
> > as well as number of OS-agnostic ones. It is not a library developer
> > role to promise an easy life to maintainers of any of the PMs/PDMs.
> > It would be a sisyphean task.
>
> That's not very considerate.
>
> If GEOS becomes too painful to maintain, I'll remove it from Debian to
> keep my sanity, and leave it up to users to build it themselves and
> integrate it with the other packages.
>
> If that requires the removal of other packages that require GEOS, so be
> it. That just reduced the number of packages I have to maintain. It's
> not in the best interest of our users, but fuck them too, right?
>
> Kind Regards,
>
> Bas
>
> --
>  GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20190517/d7503e42/attachment.html>