[GRASS5] Re: GRASS - Prototypes and encapsulation

[Andreas Lange]

Hi Markus, hi Bernard,


the CVS server is very slow now, so that i have time to comment on the
mail. Please consider my comments as my very personal opinion. 

I think that in general the concepts Bernard considered are very nice.
But there are some problematic aspects.

At first i think that we have to define the programming style before we
start to modify the source (automated or by hand). We now have no style
suggestions/standards so that it is not possible for the authors to
confine to a standard (other than ANSI-C, with which not much is won). I
would ask to give the authors active right now the opportunity to revise
their own code before changing anything automated. ( I am scared that i
can not read my own code after that ...).  

I personally feel that introducing standard documentation in the source
code will scare off authors and duplicate the effort with the GRASS
programming handbook. The whole handbook must be re-integrated in the
source in this case, which would be an herculean effort. Perhaps we can
find a solution at least for new library code. For modules i can not see
the advantage of this. 

Concerning modularization: Again my very personal opinion: I believe
that the most important thing will be to allow shared libraries/dynamic
linking. This will reduce the size of the binaries and will reduce the
whole size of the grass binary tree dramatically. It will simplify
development, as changes in the library do not require the re-compiling
of all modules depending on that library. In my opinion we should first
implement this step and then discuss again if the trouble in splitting
the whole distribution is worth the effort. Space and download
considerations IMHO do not justify the effort (there are other packets
with less functionality and bigger size). 

Language support: This includes two different topics: The language of
the interfaces (for the modules, tcltkgrass and the documentation) and
the output of multibyte characters/non ANSI characters on the CELL
driver (monitors). I think the second is more important. The first would
require some sort of "pluggable" language files, as i fear that a
complete implementation of internationalisation is too much work. This
is done very smart in TNTmips (sorry that i compare here with commercial
software), where users can provide text files with their own
translation. But with grass the approach has to consider the modularized
structure. 

Reentrant and thread-safe programming: This requires some conceptual
changes to the libraries as far as i can see. But i do not know enough
on this to dig further here. We must define our goals here too, so that
authors can write new code without introducing new problems. 


As a final clause i would ask not to start too many things at a time, so
that the single contributer is not overwhelmed with new things to learn.
This concerns only general changes that affect the whole source, not the
changes to libraries or modules. 

Please do not consider this all as criticism, i would be glad to see
your improvements. But please use this list to discuss your improvements
first.

cu,

Andreas


Markus Neteler wrote:
> 
> Dear Bernard,
> 
> thanks for your mail! I hope you don't mind that I CC to
> the GRASS 5 developers list as your mail is of interest
> for a wider audience. Please subscribe to this list to
> follow the discussion:
> http://www.geog.uni-hannover.de/grass/grassdevel.html
> 
-- 
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'