[GRASS-dev] grass is a monad?

[Glynn Clements]

Radim Blazek wrote:

> > This too is Not A Bug. Not isolating distinct operations in distinct
> > processes *is* a bug.
> 
> I can imagine almost everything done via GRASS modules. Yes, it is
> annoying to run a GRASS module (probably I have to write a new one to
> be sure, that the output/options do not change in next minor GRASS
> release)

Even if you use an existing module, the module interface is less
likely to change than a library function. Certainly, the changes to
the modules between 6.x and 7.0 are quite minor compared to the
changes to many library functions (e.g. half of G_* being renamed to
Rast_*, R_* disappearing, ...).

> and to parse output instead of just calling a function. You
> did your work well, you made our life harder.
> 
> Everything except vector editing. I don't see any reasonable
> possibility to do interactive vector editing via a GRASS module. For
> vector editing, I need immediate response which is visualized on
> display (e.g. if a vertex was moved and area topology was broken it
> must be displayed). It is impossible to open/close a vector for every
> single operation, it would take too long time for larger vectors.

For this specific case, is it possible to isolate a subset of the
vector library such that it can be used reasonably by both GRASS and
QGIS (and the wxGUI's vdigit module, which is just as bad in this
regard)?

Also, what kind of fatal errors can occur while in the middle of
vector editing that could reasonably be recovered from?

I'm not particularly averse to libraries using status returns, so long
as this doesn't:

1. propagate up to the API used by modules,
2. "infest" a large portion of the GRASS libraries, or
3. mean that fatal errors end up being signalled at the highest levels
after most of the context has been lost.

-- 
Glynn Clements <glynn at gclements.plus.com>