Re: Swig Update and questions

Strk - Thanks for the feedback.  Some more thoughts below.

> > I think this boils down to three major decisions about the SWIG bindings 
> > that need to be agreed on:
> >
> > 1. What geometry model do clients work with? Just geometry or geometry, 
> > point, line, etc.
>
> Clients should only work with the C api, unless willing
> to follow API revolutions for a couple of years.
>
> > 2.  What compatibility benefits does the C api provide beyond the 
> > benefits of the generated swig bindings?
>
> The C interface will be careful maintained binary compatible
> between versions.

Yes, but I don't think that matters for the bindings.  Binary 
compatibility is not needed because Python/Ruby dynamically load the 
bindings library and then have APIS that install the right Python/Ruby 
classes/methods (things like define_class("foo"), add_method("foo", 
"bar").  So Ruby and Python do not rely on the method layout and 
signatures of the shared library to remain the same in contrast to a C 
or C++ program would.

As an example - the change from GEOS 2.2 to GEOS 3.0 from a client 
perspective would not be noticed except for the fact that the default 
coordsequence class changed if I remember correctly (having a whole 
class removed does matter of course).  Even the exceptions - whose 
inheritance hierarchy is of course different, look exactly the same to 
the client.  The bindings do a pretty good job of insulating clients.

> > 3.  How much of GEOS's api gets exposed to clients?
>
> The smallest possible. Ideally none :)

:)  You could have been done with GEOS years ago!

> The GEOS API *is* the C-API, previous releases were insane
> in exposing that wide C++ interface.

Makes sense.  The SWIG bindings expose a bit more because they are 
exposing all the public methods of classes exposed by the c api (so all 
public methods on Line, Point, etc.)

Which leads to another question.  Should I remove the PrecisionModel and 
GeometryFactory classes from the SWIG api like the c-api has done and 
just use a shared global factory?  That would also lead the to the 
removal of the WKBWriter/WKBReader classes which would be replaced by 
global methods like in the C api.

Charlie

smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
geos-devel mailing list
geos-devel@xxxxxxxxxxxxxxxxxxxx
http://geos.refractions.net/mailman/listinfo/geos-devel