[geos-devel] Updated SWIG bindings

[Mateusz Loskot]

Charlie Savage wrote:
> I also added a geos_ruby project to Mateusz VC++ solution (and fixed
> a minor #include bug when building the C API with VC++).

Charlie,

Great job, thanks!

> Its a bit grungy in that I hard coded the path to my Ruby compiler,
> but it should be good enough to get someone started. Also note it
> creates a file called geos.dll which of course can be quite confusing
> but is required by the way Ruby loads libraries.  Thus the built DLL
> is kept under msvc/geos_ruby/debug instead of msvc/debug to avoid any
> confusion.

OK

> If there is interest I can do the same for python.  But I'm not sure
> how much those bindings are used versus the hand-crafted ones from
> Sean and Hobu (kind of silly having 2 sets of bindings if you ask me,
> but alas).

I don't know too.

> I also updated the tests a bit, but I'm a bit confused by what is
> what these days.  I see Mateusz added a bunch of unit tests (great) -
> but how do those relate to the older xml tests?

Unit tests and XML tests complement each other.
The idea is to develop unit tests (based on JTS tests) as the first fire
wall shooting potential problems.
XML tests are mostly used to test performance and very specific test
cases, modifiable on purpose.

That's my understanding :-)

> The nice thing about the xml tests is that the Ruby code could read
> them in, run the tests, and verify the results.  Obviously that
> duplicates the C code testing itself, but I think its still a good
> test of the bindings and memory management through the c api.

I believe there is no problem with that.
Unit tests mostly cover C++ API so far, so if bindings will test GEPS by
calling C API, that's wonderful.

> Last - when using the bindings from Ruby (or Python) the lack of a 
> Coordinate object is fairly annoying - particularly when dealing with
>  points. Any chance it can be exposed via the c api?

Could you draw some requirements necessary to fulfill by an object
exposed to ruby?
I believe there should be no problem, if it won't break simplicity and
C-nature of the GEOS C API.

Cheers
-- 
Mateusz Loskot
http://mateusz.loskot.net