[postgis-devel] Location Of LWAlgorithms

Obe, Regina robe.dnd at cityofboston.gov
Fri Dec 26 05:26:57 PST 2008


>> At the risk of extending this further, one of the things I really
like
>> about the Mapserver code base is that the function naming convention
>> directs one into the appropriate source file...
>> 
>> so  msLayerFree(layerObj *layer) is found in ... maplayer.c
>> and msPostGISRetrievePK() is found in ... mappostgis.c

>> Yuck. I don't really think this would work for PostGIS - having
function 
>> names sensitive to location doesn't work if you have an external API.

>> Think how much code would be broken if the codebase needs a slight 
>> refactoring/breaking down into different files, which would cause the

>> function name to change... :(

+1 Good point.  I thought about that too, but if we have function files
-- and one header for each section.  I'm not saying for each function,
just for the functions we expose publically like distance, simplify,
dump.  For things that are shared across multiple functions, we just put
in one file.  Doesn't that work?

> It is important to consider how easy it is to locate existing routines

> within the code, although this could be considered a "lack of 
> documentation" issue.

As one who spends a lot of time writing documentation, it may shock you
to find out that 
I rarely read documentation.  For me writing documentation is just a
mere exercise to get a mental picture of how things work/are organized/
or are supposed to work.  

That said I am very big on self-documentating structures.   Things so
well-organized that you really don't need any documentation to figure
out how things work except for quickly getting to the nuances.  So to me
if I've got to read the documentation to get started, then its just
illogically organized and I have no patience for that.  That said
PostGIS code is really not that badly organized.  Could be improved, but
generally it seems more or less logical and easy to figure out where
things live.


> For this example, I would argue that simplification is NOT a direct 
> property of the geometry and should reside in its own separate file 
> (e.g. lwdpsimplify.c). I think it would also make it easier if someone

> tried to add a different simplification algorithm in future.

+1 My point exactly


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



More information about the postgis-devel mailing list