[geos-devel] Swig Update and questions

[Charlie Savage]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osgeo.org/pipermail/geos-devel/attachments/20060624/64e70ef1/smime.bin