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

[Obe, Regina]

> Why not just use GCJ?  It compiles Java to object code.  That gives the 
> best of both worlds.

Hmm I thought we tried that already and it didn't work nicely?  Wasn't that what all that embed java was about or am I mistaken?  If it hasn't been tried, then I guess that would be the path of least resistance except for those cases where 
we did something in GEOS that is not done in JTS - like that elevation thingy and checkifobviouslywrong or whatever the name of that was.


> There may well be languages which allow expression of algorithms at a 
> higher level than Java (Ruby or Haskell come to mind).  Developing such 
> a language from scratch is a *huge* undertaking.  And don't forget, 
> development is about more than just the language - it's about an entire 
> ecosystem of IDEs, Profilers, external libs, linkers, runtime engines, 
> etc.  It takes years to get a language to this level of maturity, and 
> it's also not possible to do in isolation from the rest of the 
> community, IMO - to get true maturing and refinement you need input from 
> probably thousands of developers.

Admittedly this was a very crazy thought.  I wasn't thinking about generating
a full blown language - just disregarding stuff in existing that is dangerous.
And sprinkling code with meta comments that get translated by a preprocessor to real code.

Starting off with clear translations of how one thing maps to another

For example - JTS ArrayList vs. GEOS Vector<*> (I admit this may be somewhat petty)
Small objects - copy
Large objects - pointer (really the whole * & loop de loop delete in GEOS stuff is a big eyesore to me)
Persistence - begin persist;  end persist; (perhaps this is what all those garbage collectors are for)

Then there is (I forget which version of JTS I think up to 1.9 in OverlapOp.computeOverlay
which declares List splitEdges = baseSplitEdges;
which never seems to get used.

Doesn't exist in GEOS code base because - hmm - it should never have been done in the first place.  There are also minor cases like this I have seen where a temp variable is used in JTS that really didn't need to be there - but is not in GEOS because hmm its more costly in C++ code to do things like that and why?

These things are left to the discretion of the C++ person to omit/accept - and why they didn't voice this back to the JTS community is beyond me (or maybe it just didn't seem relevant and with my clueless eye every difference seems relevant :)).

Thanks,
Regina




-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/geos-devel/attachments/20080925/d8a8ecc6/attachment.html