Re: Swig Update and questions

Thanks for the info Sean.

If the swig bindings used the C api and did the same check for the geom 
type, would there be any difference between them and the Python 
bindings?  Are they any specific python features you added to them to 
make them easier to use from Python?  Anything that couldn't be done in 
SWIG?  Just wondering if we can combine efforts here.

Charlie

Sean Gillies wrote:
> On Jun 24, 2006, at 6:02 PM, Charlie Savage wrote:
>
> > > We surely want them distributed. We also want to distribute the 
> > > generated
> > > wrapper (for those not having unstable swig installed).
> > > Would be nice if make maintainer-clean would get rid of the latter
> > > and next make would recreate it.
> > > (haven't tested your new makefiles yet)
> >
> > Okay, so I need to add in a hook for make maintainer-clean then and to 
> > have make check to see if the generated wrapper exists or not and 
> > create if needed (I think the makefiles already do that actually).
> >
> > Anything I need to do for getting the files into the distribution?
> >
> > Haven't checked in my changes yet, I want to first test them some more.
> >
> > > > * Who owns the geometries returned from methods such as 
> > > > Intersection, Difference, etc?  The C API doesn't give any 
> > > > indication and it wasn't obvious to me looking through the C++ code.
> > > A rule of thumb for the C API is:
> > > Every Geometry caller should take care of is returned
> > > as a non-const object.
> > > For these specific case the caller must delete them.
> >
> > Okay, so the caller needs to delete the results of methods like 
> > Intersection.  Assumedly the same goes for using the C++ api - i.e, 
> > geom->intersects(someOtherGeom)?
> >
> >
> > While on the subject, I've taken a look at what would be involved with 
> > having the SWIG wrappers use the C api.  Its doable - basically I 
> > would have SWIG create "fake classes" which look like classes to 
> > Ruby/Python but underneath use the C API.  This is how the GDAL swig 
> > bindings are implemented, so its ok.  It is a bit silly (duplicate 
> > definitions), but it works.
> >
> > But the thing that holds me back is that in the c-api all the geometry 
> > types get merged into just Geometry (no points, linestrings, etc.). 
> > That might be ok for C, but me would seem very strange in Ruby or 
> > Python.  I've thought its too high too high a price to pay and thus
> >
> > But I wonder if there is a way around this by using a variation of the 
> > PIMPL idiom (http://www.gotw.ca/publications/mill05.htm)?
> >
> > Something like forward declare all the Geos geometry classes, but of 
> > course don't call any methods on them.  Then for any C-API method that 
> > returns a geometry do a dynamic_cast to see what it is and then return 
> > an appropriate SWIG wrapper classes.
> >
> > Sean or Hobu - didn't one of you write your own bindings for Python 
> > not using SWIG?  How did you handle this?  Are you happy with just 
> > having a Geometry object and you have to make sure to use it correctly 
> > (if its a point don't call NumRings)?  Or did you do something more 
> > clever?
>
> Charlie,
>
> I'm doing something similar to your idea above. When a generic geometry 
> is returned from a method, I check the GEOS type and then change the 
> class of the result object to Point, LineString, etc.
>
>
> > In the end though I wonder if there is any real benefit to using the C 
> > api for the swig bindings. The c-api is supposed to insulate a program 
> > from changes to the underlying C++ api.  But the bindings libraries 
> > already do that.  Python/Ruby will dynamically load the bindings and 
> > install the appropriate classes/methods.
> >
> > That means can install a new version of GEOS, swap out the bindings 
> > library, restart your program, and all should be well as long as you 
> > haven't removed any methods (it doesn't matter if methods or classes 
> > or changed namespaces or changed hearder files or whatever).  Now if 
> > you swapped out the version of GEOS and not the bindings, then you'd 
> > run into problems (but you would also with the C-API).
> >
> > There is also the point that everything is statically linked on 
> > Windows  (since geos doesn't export any functions), so it doesn't 
> > matter at all if the version of geos is changed on the machine.  You 
> > could do the same on Linux/Unix I suppose.
> >
> > Well, after all that rambling I've talked myself back into the idea 
> > that the SWIG bindings should stick with the C++ api because the C api 
> > provides no forward compatibility benefit (it does provide benefit, or 
> > disadvantage depending on your viewpoint, of a much smaller API).  But 
> > I'm more than happy to listen to counter arguments and do the work to 
> > switch over to the C api if its demonstrably better.
> >
> > Charlie
> > _______________________________________________
> > geos-devel mailing list
> > geos-devel@xxxxxxxxxxxxxxxxxxxx
> > http://geos.refractions.net/mailman/listinfo/geos-devel
>
> ---
> Sean Gillies
> http://zcologia.com
>
>
>
> _______________________________________________
> geos-devel mailing list
> geos-devel@xxxxxxxxxxxxxxxxxxxx
> http://geos.refractions.net/mailman/listinfo/geos-devel

smime.p7s
Description: S/MIME Cryptographic Signature

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