<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-2">
<META content="MSHTML 6.00.2900.2802" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff>
<DIV><SPAN class=474014501-31032006><FONT face=Arial color=#0000ff size=2>Good
point about splitting the initial conditions out from the GeometryFactory.
I was trying to reduce the number of classes - but maybe that's somewhat less
flexible.</FONT></SPAN></DIV>
<DIV><SPAN class=474014501-31032006><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=474014501-31032006><FONT face=Arial color=#0000ff size=2>And
yes, this is all trivial in Java - I commiserate with you C++ guys....
8^)</FONT></SPAN></DIV>
<DIV><SPAN class=474014501-31032006><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=474014501-31032006><FONT face=Arial color=#0000ff size=2>I
would think smart pointers would help here. As for a default factory,
that probably makes a lot of sense for 98% of users - so seems like a good
idea.</FONT></SPAN></DIV>
<DIV><SPAN class=474014501-31032006><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=474014501-31032006><FONT face=Arial color=#0000ff
size=2>Martin</FONT></SPAN></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV align=center><FONT face=Arial size=2><STRONG>Martin Davis, Senior Technical
Architect</STRONG><BR><STRONG><FONT color=#0000ff>Vivid Solutions
Inc.
<I>www.vividsolutions.com</I></FONT></STRONG><BR></FONT><EM><FONT face=Arial
size=2>Suite #1A-2328 Government Street Victoria, B.C. V8T 5G5<BR>Phone: (250)
385 6040 - Local 308 Fax: (250) 385 6046</FONT></EM></DIV>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT
face=Tahoma size=2>-----Original Message-----<BR><B>From:</B>
geos-devel-bounces@geos.refractions.net
[mailto:geos-devel-bounces@geos.refractions.net] <B>On Behalf Of </B>Charlie
Savage<BR><B>Sent:</B> March 30, 2006 5:41 PM<BR><B>To:</B> GEOS Development
List<BR><B>Subject:</B> Re: [geos-devel] GeometryFactory - call for
explanation<BR><BR></FONT></DIV>Thanks for the explanation Martin. Seems
like that is a workable design in Java, where the garbage collector worries
about freeing the factories for you when they are no longer referenced by any
geometries. I suppose I would probably split out the initial conditions
into some other object - so the factory just creates geometries. But in
the end, that doesn't change the issue I brought up.<BR><BR>So, in C++ Geos
could we use smart pointers to achieve the same effect? And maybe add in
a default global factory?<BR><BR>Charlie<BR><BR>Martin Davis wrote:
<BLOCKQUOTE
cite=mid5A94289A9268514C8D6C0F1FF44BA0279C3F28@venus.VividSolutions.com
type="cite"><PRE wrap="">Those assumptions are correct.
There were two main reason for designing the GeometryFactory concept:
1) Provide a convenient, single location for defining the various "initial conditions" for Geometries. This includes the Precision Model, the CoordinateSequenceFactory, and sometimes the SRID. It may be extended in the future to contain things like which Polygon model to use, and preferences for precision handling.
2) Reduce the memory overhead of Geometries by moving relatively static objects (references) out of the Geometry and into a single shared object.
Hopefully this makes sense... But if anyone has good opinions about another design pattern, send them along.
Martin Davis, Senior Technical Architect
Vivid Solutions Inc. <A class=moz-txt-link-abbreviated href="http://www.vividsolutions.com">www.vividsolutions.com</A>
Suite #1A-2328 Government Street Victoria, B.C. V8T 5G5
Phone: (250) 385 6040 - Local 308 Fax: (250) 385 6046
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">-----Original Message-----
From: <A class=moz-txt-link-abbreviated href="mailto:geos-devel-bounces@geos.refractions.net">geos-devel-bounces@geos.refractions.net</A>
[<A class=moz-txt-link-freetext href="mailto:geos-devel-bounces@geos.refractions.net">mailto:geos-devel-bounces@geos.refractions.net</A>] On Behalf Of
Mateusz Loskot
Sent: March 30, 2006 5:10 PM
To: GEOS Development List
Subject: [geos-devel] GeometryFactory - call for explanation
Hi,
Could anyone explain/confirm me assumptions behind
the GeometryFactory class?
Depending on its semantic I'd have some proposal to refactor
it. Here are my qusetions:
Are following assumptions correct?
1. Ever instance of Geometry type (or its subtype) can have
assigned its own instance of GeometryFactory
2. One instance of GeometryFactory class can be shared
(assigned to) between more than one objects of Geometry class
3. It is not assumed that all geometries share the same
common instance of GeometryFactory
Thanks in advance for comments
Cheers
--
Mateusz Łoskot
<A class=moz-txt-link-freetext href="http://mateusz.loskot.net">http://mateusz.loskot.net</A>
_______________________________________________
geos-devel mailing list
<A class=moz-txt-link-abbreviated href="mailto:geos-devel@geos.refractions.net">geos-devel@geos.refractions.net</A>
<A class=moz-txt-link-freetext href="http://geos.refractions.net/mailman/listinfo/geos-devel">http://geos.refractions.net/mailman/listinfo/geos-devel</A>
</PRE></BLOCKQUOTE><PRE wrap=""><!---->_______________________________________________
geos-devel mailing list
<A class=moz-txt-link-abbreviated href="mailto:geos-devel@geos.refractions.net">geos-devel@geos.refractions.net</A>
<A class=moz-txt-link-freetext href="http://geos.refractions.net/mailman/listinfo/geos-devel">http://geos.refractions.net/mailman/listinfo/geos-devel</A>
</PRE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>