[postgis-devel] Location Of LWAlgorithms

[Obe, Regina]

>  Obe, Regina wrote:
> 
> > I really like the naming convention idea but as far as bunching up
I'm 
> > almost thinking GASP - a separate file for each public function, a
file 
> > for shared functions that are reused across but not public.  like an

> > lwsimplify.c kind of like we have lwgeom_kml.c, lwgeom_transform.c,
in 
> > the lwgeom folder.   But I guess that could  become silly given the 
> > number of functions we have.

> -100

> I think if we did this the maintenance overhead of liblwgeom would 
> quadruple overnight as we'd have to spend considerably more time 
> managing header files.

I still don't quite get this header file thing.  It seems every file
doesn't have a header file.  Why is that?
Looks like most of the  externs are stuffed in liblwgeom.h in which case
I fail to see the maintenance nightmare
you are talking about except of course for existing stuff.  Which I
would wait off repairing anyway.

I guess my point is if I'm creating a function -- its unclear where to
put it.  
For example azimuth?  We have azimuth in lwgeom_spheroid.c for
spheroids, we have it in liblwgeom/measures.c.  If I didn't know
measures existed and I was creating a distance function, I'd probably
stuff it in basic or algorithm.  I mean I have to way is distance more
of a measure or an algorithmic or a basic.  If I didn't have a full
command of English, I hesitate to think what I would think.

Now we could simply stuff everything in one file, but even as good as
SVN is I'd have to wait for Paul or you to finish your changes before I
could make my changes. Not very pretty. If I were creating some very
powerful spatial function to change the world -- I'd simply stuff my
externs in the .h and spend the brunt of my time in the .c and take a
long time before check in.  


> > I guess my thinking is in mapserver there is a natural workflow. 
> > Everything is working to make a map and every element in the
mapserver 
> > hierarchy plays a fairly unique well-defined role where as in
PostGIS, 
> > there is no defined workflow to my knowledge and each geometry plays
the 
> > same role - to be stuffed in a meat grinder device of sorts.

> +100

> In Mapserver, the code layout is strongly influenced by its object 
> hierarchy. And as you correctly point out, PostGIS really has no such 
> concept.


> ATB,

> Mark.

So does this mean we already live in an optimal world
given our compromises.  Personally I don't have too many problems
finding things.  I just do a 
search across the code base and generally functions except for shared
ones reside in the same file they work with.  As long as things are in
close proximity to the things they work with I'm more or less happy.
Just more of an issue when trying to add new functionality.




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