[postgis-devel] Location Of LWAlgorithms

[Obe, Regina]

Mark,
That sort of works.   Honestly I'm not quite as opinionated as I come
off sounding.  I just like playing devil's advocate.  If Paul wanted to
go the functional route I'd probably be sitting here coming up with
reasons why his thinking is flawed.

I guess the only issues I have with this is that 
1) it takes too much brain power and context switching when my mind is
thinking about distance, buffer, translate, num dimensions etc which is
most of the time, I could F**** care what kind of geometry I'm dealing
with.  I just want to 
see X algorithm in one file so I don't have to flip thru 20 files.  Of
course I guess that is taken care of by your proposal -- except what
exactly is a lower level function? I have a vague idea of what that is,
but it is not deterministic.  And that bothers me.  See 2.

2) Now I have to think -- "hmm is this a higher algorithm or lower
algorithm? to figure out where to look" 

Take the case of ST_Multi - now I would think that is a lower algorithm
because clearly its the property of 
a geometry type. (or do you consider it a Class function rather than an
instance function) and where do we put Class functions exactly - do we
lump it in with the accessors or constructors.

a) First you've got to open up the Multi stub function -- because hey
PostgreSQL needs one function to latch on to so we need stub functions
anyway.  Or am I missing something here.  

b) Then your stub does some sort of case to call the correct
lwgeom_is_has_multi or whatever. Okay now I have to follow those cases
into (hmm how many geometries do we have?) files to figure out what that
does.

3) So not only is an object view (are rather should I say noun objects,
I'm all for verb objects - down with nouns) flawed as far as spatial
operations are concerned, it doesn't really fit well in the
PostgreSQL/C/PostGIS connectivity way since we have one geometry
PostgreSQL type to cover all our different geometry types.

Thanks,
Regina



-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Mark
Cave-Ayland
Sent: Wednesday, December 24, 2008 9:13 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Location Of LWAlgorithms

Paul Ramsey wrote:

> 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.

For me, the common sense approach would be to think with an 
object-oriented brain. So I would argue that direct properties of items,

e.g. length of linestrings, areas of polygons etc. should live in the 
individual lwline.c/lwpoly.c files. For higher level algorithms, e.g. 
calculating clipping/intersection points, the code should live in your 
separate lwalgorithm.c file. Does that help at all?


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
_______________________________________________
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.