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

[Martin Davis]

Obe, Regina wrote:
>
> > 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 were unclear issues with GCJ.  If it can be made to work, it would 
be a huge win I think.
>
>
>
> > 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.
>
IMO, I don't see this as being viable for a codebase as complex as 
GEOS.  I think it would be very hard to debug the "high-level" preproc 
instructions, given that you'd have to debug them at the 
processed-source level. 

But I'd be happy to be disproved by an existence proof...  8^)

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022