[GRASS5] OOP and 3rd party libs

[Andreas Lange]

Hi developers,

i do not feel qualified to answer those questions, but i want to tell my
opinion. 

David D Gray wrote:
> 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.

There is some code named "eigen_tools" (G_tqli, G_tred2), but i do not
know anything about it. If there is need for such a library, no
objections.  

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

If some module/function/library is only available in Fortran and the
code can be compiled with g77, i have no objections to including Fortran
code. But maybe it would be simpler to convert the whole module with f2c
to avoid possible compiling problems. 
But the coordinate transformation and the projection support in grass
(corcnv lib and proj lib) do not rely on any fortran code. I don't think
that there are really problems with speed or efficiency in those
libraries, proj e. g. is very well designed and proven. 

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

I personally do not like C++ and do not plan to program in grass with
C++. The problem will be that the C++ code should not introduce any
portability/compiler problems. I think GRASS should be portable to many
Unix and Unix-like systems and should not rely only on GNU egcs/g++
compiler. But again, if some functionality is only available with C++
and someone is able to integrate and document this, no objections. 
 
> 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.

If the library has real benefits for GRASS, is needed for a
module/function in GRASS, gives better maintainability and performance
and has a compatible License (GPL/LGPL/BSD/PD) we should include it. 
But i think that this cannot be decided in general, we should discuss
this as needed. 
 
> 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 personally think that incorporating OOP into an existing system has no
big benefits. GRASS' libraries have been developed in pre-OOP times and
i fear that wrapping this up into a OOP system will be very difficult. 
The database structure and function semantics in GRASS are not object
oriented, but task oriented. All the late-coming systems had the benefit
that they could implement a clean OOP system from the beginning. 
I would like to program in a script language (i know tcl/tk and Perl,
but both are not suited for GIS tasks) instead of writing C-Programs. I
had a glance at Python and think it is worth learning. 
But overall i think that much simpler enhancements (e. g. to the
xdriver) will give a bigger effect with much lower workload than
redesigning the library to OOP.

cu,

Andreas

-- 
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange at Rhein-Main.de, A.C.Lange at GMX.net



---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'