[geos-devel] GeometryFactory - call for explanation

[Mateusz Łoskot]

strk at refractions.net wrote:
> 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.

It should work well.

> 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. [...]

I understand and agree.
As you said, first we should focus on basic refactoring, ad'hoc fixes of
serious bugs we'll find and finishing Unit Tests.
I believe this week the plan will be finished regarding Unit Tests.

Next, we could create a branch for next step of refactoring that will
include deeper changes like incorporating smatr pointers, changing the
GeometryFactory etc.

Regarding the branch. May be it could be good time (after the first
stage we are in now, but before the next step) to switch to SVN?

> 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.

The main idea behind the "named constructor idiom" I know is to prevent
user from creating object directly, on stack or heap, using common
constructors. The second idea is to prevent users from creating object
on the stack, if we wish because of some design decisions.
Then, named ctor can assure the object will be created only on the heap.

In our case (yet another option), we could prevent user from creating
Geometry directly but only using GeometryFactory.

What is the best solution for GEOS?
What are the design decisions we should follow?
I'm not sure for now, because of lack of knowledge behind JTS design.

> 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.

I don't understand.

In general, shared_ptr idea is to free users from knowning *where* is
the object and *who* is using it. Simply, object managed by shared_ptr
is there where it is use and it will live as long as it is required.

So, as the name suggests, object managed by shared pointer is shared
between a number of objects. So, those client objet also share the state
of object managed by shared pointer. If this state changes, then all
clients see that change.

So, how those rules apply to the problem above?

> 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.

Good idea.

> 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 ?

I understand it but I think GEOS users are able to answer it best.
>From my point of view (a library hacker) the situation is less complex.

> 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.

Hmm, it depends on how many people could work on it.
I don't know how many developers work on GEOS currently.

Now, I'm not able to work on it in full time, so as you - Sandro - can
see, there may be some delays as with e.g. Unit Tests that should be
finished 1-2 weeks ago as we talked.
If I would be able to work on GEOS 8-10 hours a day, then it was
finished in 3-4 days.

Similarly, if there are 2-3 developers able to work on GEOS 8 hours a
day, then that 2 months period could be anough to make next generation
of GEOS stable.

I think GEOS PSC can decide.

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