[GRASS5] OOP and 3rd party libs
David D Gray
ddgray at armadce.demon.co.uk
Tue Jun 6 11:17:05 EDT 2000
Hi developers
I have been giving some thought recently to the question of third
party libraries in the GRASS environment, and how far we
might want to go in incorporating them into the main
distribution. To give a few of the matters arising:
1. Most large scale projects in the number-crunching zone,
whether they are free software, open source, public domain,
or whatever, incorporate some form of the BLAS/LAPACK libraries
for efficient linear algebra computations. Am I right in thinking
GRASS does not have this? Its presence would take a lot of
the burden away from developing separate routines in each module
and allow developers to concentrate on GIS specific code.
2. As an extension to the above there is the whole question of
linking to Fortran code. We already have some Fortran routines.
Do we have any Fortran developers? If I am right, this was
settled in the GRASS camp about 10 years ago - long before my time -
when it was decided as policy that future development would
concentrate on C and Fortran routines would be deprecated.
This is fine as far as it goed but I don't think we should
reject external Fortran routines if they do a specific job
more efficiently, and in any case will be maintained by others
who have skills more appropriate to the task, eg. mathematicians.
I am thinking of things where heavy repetitive number-crunching is
involved - co-ordiantes transformations, as in projection support,
possibly, finite element analysis, stats or (as above) linear algebra
routines.
3. Extending further, what about useful libs in other languages.
There is a lot of code in C++, and some in Ada95, that might be
useful. Again even if we are not using these languages ourselves
they are widely cross-platform and easy to link to C code. It is
much easier to find implementations of B-trees, RSTrees and the like
in C++ than in C, and they are often well-maintained.
4. Then - how much do we want ot rely on third party libraries?
They will generally be maintained by others, though they will
be GPL/BSD licensed, so we should be able to modify/improve them
as we see fit, and return the results to the broader community.
5. Finally, what about OOP. DO we want to start developing OOP
rouitnes within GRASS itself. I know some people regard OOP as
unnecessary, but others might feel the edge it gives development
to be indispensable. Others don't like C++. But there are
other options: Ada95 I have mentioned, and we have already
had numerous postings where people have praised Python as a
worhty development language for GRASS (with which I concur). There
is also Objective-C, which is more like a `natural' extension to
C itself, but is perhaps not so portable right now.
I would be interested to know if anyone else has had any
thoughts on these matters, and if so what they see as the
way forward.
Best wishes
David
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'
More information about the grass-dev
mailing list