[geos-devel] Unclear objects lifetime and ownership issues in Monotone Chain components

[Mark Cave-Ayland]

On Wed, 2008-09-24 at 22:50 +0200, Mateusz Loskot wrote:

> The only solution I can imagine is to take JTS algorithms, one by one,
> re-analyse them and re-implement (sometimes re-design a little) having all
> these issues in mind. So, final implementation fulfills requirements of
> Martin's algorithms as well as fits well into conditions of C++.
> 
> AFAIR, we've talked about these kind of problems in GEOS a few times
> but no one is brave enough to apply discussed ideas to the code.
> Everybody is able to imagine it would require a lot of work.

I think long term that this will be the only sensible way to go. There
are many different paradigms in programming which are incompatible with
each other, and translating an algorithm direct from a GC environment to
a non-GC environment is one of these IMHO.

GEOS is a great proof-of-concept piece of code and we are all grateful
to Sandro, Mateusz etc. for the work that they have put in. But the
warning bells start to ring when even the people who work on the code
are unable to understand or maintain it - a lot of the work in PostGIS
SVN at the moment is related to tidying up code / adding debug support
which is designed to simplify things for developers, and make us (me?)
less likely to break things in the future when adding new features.

If I had a choice then it would be to spend the time re-engineering
Martin's JTS concepts/ideas into an algorithmic form which is friendly
to the language it is being written in, rather than trying to hack in
pointer reference counting. Work with the language, not against it. 

Having GEOS shadow JTS would be great in a perfect world, but the
reality is that the reduced cost in implementing new features comes at
the massive increased price of ongoing maintenance. While we are there,
let's chuck in a hierarchical memory manager (like PostgreSQL's palloc()
- maybe Samba's talloc() ?) so we can reclaim memory on a per-context
basis and eliminate memory leaks at the same time.


ATB,

Mark.