<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>RE: [geos-devel] Unclear objects lifetime and ownership issues inMonotone Chain components</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>> Why not just use GCJ? It compiles Java to object code. That gives the<BR>
> best of both worlds.<BR>
<BR>
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<BR>
we did something in GEOS that is not done in JTS - like that elevation thingy and checkifobviouslywrong or whatever the name of that was.<BR>
<BR>
<BR>
> There may well be languages which allow expression of algorithms at a<BR>
> higher level than Java (Ruby or Haskell come to mind). Developing such<BR>
> a language from scratch is a *huge* undertaking. And don't forget,<BR>
> development is about more than just the language - it's about an entire<BR>
> ecosystem of IDEs, Profilers, external libs, linkers, runtime engines,<BR>
> etc. It takes years to get a language to this level of maturity, and<BR>
> it's also not possible to do in isolation from the rest of the<BR>
> community, IMO - to get true maturing and refinement you need input from<BR>
> probably thousands of developers.<BR>
<BR>
Admittedly this was a very crazy thought. I wasn't thinking about generating<BR>
a full blown language - just disregarding stuff in existing that is dangerous.<BR>
And sprinkling code with meta comments that get translated by a preprocessor to real code.<BR>
<BR>
Starting off with clear translations of how one thing maps to another<BR>
<BR>
For example - JTS ArrayList vs. GEOS Vector<*> (I admit this may be somewhat petty)<BR>
Small objects - copy<BR>
Large objects - pointer (really the whole * & loop de loop delete in GEOS stuff is a big eyesore to me)<BR>
Persistence - begin persist; end persist; (perhaps this is what all those garbage collectors are for)<BR>
<BR>
Then there is (I forget which version of JTS I think up to 1.9 in OverlapOp.computeOverlay<BR>
which declares List splitEdges = baseSplitEdges;<BR>
which never seems to get used.<BR>
<BR>
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?<BR>
<BR>
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 :)).<BR>
<BR>
Thanks,<BR>
Regina<BR>
<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>
<HTML><BODY><P><hr size=1></P>
<P><STRONG>
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.
</STRONG></P></BODY></HTML>
<P><hr size=1></P>
<P><STRONG><font size="2" color="339900"> Help make the earth a greener place. If at all possible resist printing this email and join us in saving paper. </p> <p> </font></STRONG></P>