[geos-devel] GeometryFactory - call for explanation

Mateusz Łoskot mateusz at loskot.net
Thu Mar 30 21:10:53 EST 2006


Charlie Savage wrote:
> While on the subject of geometry factories....
> 
> Would it be possible to add a global, default factory?  This would be
>  very helpful when accessing GEOS from scripting languages like ruby
>  and python.

Should it be global?

> The first issue it would solve is worrying about keeping geometry 
> factories alive for longer than the geometries themselves.  This is 
> tricker than it sounds because at least in Ruby you're dealing with a
>  mark and sweep garbage collector.  So what I do in Ruby is create a 
> global factory and always use that.

I'm not an experienced implementor of binding to scripting environment,
but I'd say shared_ptr will solve the problem.
Smart pointer is just a garbage collector.
Shared smart pointer tracks all its clients and will collect the object
it manages only after the last client will disconnect.
Does it look ok for you?

> However, that solution breaks down when dealing with marshaling 
> objects.  Ruby has the concept of marshal/unmarshal like a lot of 
> other languages.  Since GEOS is in C, these methods need to be 
> implemented in C++ (as part of the SWIG bindings).

AFAIK GEOS is in C++ :-)

> Thus, since I'm in C++ I don't have easy access to the geometry
> factory I created on the Ruby side.  Thus in C++ I can create a
> GeometryFactory as a global of some sort fully realizing it will
> never be freed and thus leak memory.  The alternative is worse,
> create the factory, create the geometry, free the factory, get a
> segmentation fault.

My option is to let the factory be collected automatically when it is
not used anymore - by smart pointer, a garbage collector.


> Of course, removing the dependency between geometries and factories 
> would be even better.

Definitely, but there seems to be a good reason that every geometry
knows its factory. I mean, it's not very uncommon :-)

Another option is to make it possible to do both:
- create geometry with assigning the factory to it
- create geometry without assigning the factory to it (or assign shared
default factory automatically, but I'm not sure such factory will be
usable in all cases)

> I have no idea if its possible since I haven't looked at that part of
> the code - but it is a bit annoying having the back reference from
> geometries to factories to have to worry about.

That's why I've started this thread.
My idea is to make it not necessary to
track "where is my factory" back :-)

But note, that this is not very uncommon that geometry knows its
factory, e.g. for further usage/modification of this geometry.
Simple example:
You have an instance of the GeometryCollection class and theFactory
object is assigned to this geometry. You've configured this factory
according to your needs (PrecisionModel, etc.).
Now, you want to create and add new (sub)geometry to this collection.
Would you prefer to create new factory? I would not.
The most convenient is to query theFactory object from the
GeometryCollection instance (let's call it Master Factory) and use it to
create (sub)geometries that will be added to this collection.
This way all geometries will use common conditions (PrecisionModel, etc.)


Cheers
-- 
Mateusz Łoskot
http://mateusz.loskot.net



More information about the geos-devel mailing list