[geos-devel] GeometryFactory - call for explanation

[strk at refractions.net]

On Fri, Mar 31, 2006 at 10:38:04AM +0200, Mateusz Å?oskot wrote:
> strk at refractions.net wrote:
> > All three assumptions are correct.
> > I'd add in (1) that each instance MUST have a GeometryFactory
> > assigned.
> 
> 
> OK, so let default constructor(s) of geometry class(es) get factorry
> from external source - passed as a ctor param - or if no factory is
> passed, then Geometry ctor calls GeometryFactory::defaultFactory().

Yes, this is how I think it should work.
Note, though, that I'm not sure this is the right time for it.
I prepared the road for these kind of changes by providing
a C api, but not everybody switched yet.
A small part of the C++ API is dangerous land we should try
not to mess too much with, to at least allow API compatibility.
Note that qgis currently builds against GEOS-HEAD, but would
likely NOT build if we introduce changes there, unless much
care is taken.

For example: do you guys think Geometry and subclasses should
have PRIVATE (or protected) constructors ?
If we can guarantee that no clients build geometry by their
constructors, but keep using the Factory idiom, we have
no problem changing the constructors.
Also, how can a GeometryFactory know where is shared_ptr is 
in order to pass it to a Geometry Constructor ?
I mean, making *this* change likely breaks *every* GEOS client.

There are a lot of other places that could take advantage 
of boost::shared_ptr<>, and many are to be considered "internal".
So my strategy is to first "reduce" the API to be able to
tell what's "external" and what's "internal". Then, introduce
shared_ptr in the "internal" part, and "finally" reach the
API, likey reintroducing a form of ABI compatibility control.

About the ABI comp. control: what I decided some time ago
was to ship libgeos-Maj.min.mic.so, practically making
*every* release unused by existing code. This is what I
call "drop" the ABI compatibility control.

The alternative would be shipping next release as
libgeos.so.3.0.0.so and "defend" the ABI. Since it
seems there are more people involved in development now,
do you really think this would be possible in 2 months ?

To state it more clearly: do you think 2 months are enough
to give geos a *new* *backward-incompatible* but *abi-stable*
interface ? I'm personally NOT sure, and I think *reducing*
the interface would already be a good step forward.

Comments welcome.

--strk;