[postgis-devel] Location Of LWAlgorithms

[Obe, Regina]

I haven't taken that thorough a look at the code base, so perhaps I shouldn't be speaking.

But I would think that there are many functions that deal across geometry types
or functions where most of the functionality is the same for different types.

So I fear if we tried to make it a rule, we would quickly violate it simply out of efficiency.  Would seem better to separate the algorithmic nature from the constructive nature.

I know I'm supposed to be an object oriented programmer -- so perhaps the OO gods will shoot me where I stand for saying this.

To me geometries are dead objects to be worked on.  Functions are the focal point as far
as spatial is concerned.





-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net on behalf of Paul Ramsey
Sent: Tue 12/23/2008 2:12 PM
To: PostGIS Development Discussion
Subject: [postgis-devel] Location Of LWAlgorithms
 
I've started an lwalgorithm.c file. However, I see some functions are
living with the types they work against. ptarray_substring, for
example. By a similar token, area should move to lwpoly and lwmpoly
implementations for area. Anyone have a problem with a general rule of
locating methods with their objects, or should we keep the object
files restricted to constructors/accessors and put all the
calculations elsewhere?

P.
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel







-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20081223/657f6786/attachment.html>