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

[Martin Davis]

I've know about NTS since it's inception, Regina.  As you say, they had 
a *much* easier time of porting it.  And it's lucky for them that it 
tracks so closely - saves them having to think when bug fixes & new 
features are added to JTS...  8^)

Do you know how "inefficient" GCJ is?  Maybe it's not that bad at 
all...  As long as its garbage collector is efficient it could be 
similar performance to Java.  AFAIU garbage collectors can be as 
efficient if not more so than manual memory management.

Carry on with your language research...  There's a PhD there for you at 
least if you crack that one.

Obe, Regina wrote:
>
> Martin,
>
> > This seems like it might be building GEOS to be a bit too specific to
> > its use in PostGIS, however.  I think there's lots of people who want to
> > use it in other environments.
>
> Slightly off-topic - but have you been looking at how those evil C# 
> people have been interpreting JTS?
> http://sourceforge.net/project/showfiles.php?group_id=144924&package_id=159419&release_id=443988 
> <http://sourceforge.net/project/showfiles.php?group_id=144924&package_id=159419&release_id=443988>
>
> Although I think they have a much easier time porting JTS code - since 
> well C# doesn't have to worry about all that pointer arithmetic 
> minutia and its syntax is much closer to Java (e.g. they have 
> ArrayList too) so is a closer one to one code compare with JTS.  In 
> fact - its almost identical code except for some casing choices to 
> conform to C# standard here and there and use of IEnumerator vs 
> iterator.  Scary close.
>
> I, feeling somewhat attached to the evil empire - can't help but point 
> out these irrelevant similarities :)
>
> I'm still working on the proof of existence theorem - although I am 
> leaning toward the direction of a meta language
> that no one actually programs in but that enforces a certain level of 
> rigidness such that (ala Microsoft's IL where a VB.NET compilation to 
> IL is almost as efficient as C# to IL or C--)
>
> Valid Transform(JTS, TSM) -> implies - Transform(TSM, GEOS) is efficient
> Valid Transform(GEOS,TSM) -> implies - Transform(TSM,JTS) is efficient
> Valid Transform(NTS, TSM) -> implies - Transform(TSM,JTS) , 
> Transform(TSM,GEOS) is efficient
>
> By the simple fact it chokes you know there is no way in gods hell of 
> making it efficient without significant rewrite or tinkering with the 
> transform function.  What exactly that magical function looks like (if 
> it exists) I'm still stirring in my head (I suspect it involves 
> cataloging the various patterns of programming in each). 
>
> The problem I have with things like GCJ conversions (talking from the 
> side of my mouth since I don't quite understand them) is
> they just guarantee at best the code will run but not that it will run 
> efficiently in the new environment.  I also tend to think the task is 
> much more simple if you limit the scope of possibilities whereas a 
> bytecode full blown thingy has to consider everything.
>
> 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. *
>
> ------------------------------------------------------------------------
>
> * Help make the earth a greener place. If at all possible resist 
> printing this email and join us in saving paper. *
>
> * *
>
> * *
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel

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