[GRASS5] Proposed process for GRASS reorganization (please read)

[strobe anarkhos]

>Less generally, I'm not very keen on generalized models or on OOP.
>
>OOP is a reasonable way to organize a large programming effort in a
>corporate or academic environment with a top-down organization.  Currently
>GRASS development seems to be based more on consensus-building, which I
>think is typical and possibly necessary in volunteer efforts.  So I'm not
>so sure that OOP is good for our setting.
>
>Maximum operational efficiency comes from code that is organized to
>complete a specific task.  Where I've seen code developed on generalized
>schemes the results have been much less efficient.

I was also a huge skeptic about OO programming until I started using Objective-C (which wasn't long ago!). Prior to that I had been using C++ with others and on personal projects for several years. I still use C++ occasionally, but it really painful. C++ is necessarily very very strict because it uses static link tables instead of runtime linking.

Objective-C changes everything especially when combined with Foundation. It is used by many developers who work alone. It actually does make development of SMALL projects very easy indeed. 

Objective-C objects are also more interchangeable and it's easier to make changes in design if so wished. It truely is awesome and it's pretty sad that C++ took hold. It's also a million times easier to learn and use.

I empathize completely with your skepticism about OO programming. Objective-C and Foundation however fit this project like a GLOVE.

We also have two Java<->Foundation bridges which already work. One is open source and multi-platform and the other is Apple's which I've used a little. I'm not a huge proponent of Java (as a language it's not that good) but there are tons of Java developers.

Apple's documentation is top notch but to know how easy it is to use, you have to use it. It's all theory and skepticism until you actually apply MVC methodology using Cocoa or GNUStep. 

>Certainly if the developers were to consider such a sweeping change in
>the structure of GRASS they would need to review some more specific
>suggestions about how the current code would be merged into the new
>structure.

I understand completely. If I were to write anything more specific I would have tripled the size of my email and nobody would have read it. Plus I would have had to bone-up on the internals of GRASS.

If people show interest the first step would be writing the basic model and implementing persistence. After then we have a clear path of execution in terms of adding methods and so on. Organization takes care of itself for the most part once the basic model is outlined.

>
>Finally and most specifically, your discussion omitted the GRASS "sites"
>map type.  You used the term "site" for other purposes in describing the
>program structure, so your proposal at the very least needs to be reworded
>to account for the third map type.

I admit I don't know all aspects of GRASS internals like the back of my hand, but the purpose of the hypothetical class arrangement was a demonstration of how the model hierarchy would be created.

My main reference thus far has been the GRASS 5 Developer's Manual PDF.


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