[GRASS-dev] RFC: Module Option Parser

[Daniel Calvelo]

On 12/22/06, Florian Kindl <florian.kindl at uibk.ac.at> wrote:
> On Dec 22 [ 9:36], Markus Neteler wrote:
> > Glynn Clements wrote on 12/21/2006 06:50 PM:
> > > Brad Douglas wrote:
> > >
> > >
> > >>> If most of the options only apply to a specific "mode", that suggests
> > >>> that each mode should be implemented as a separate module. If they
> > >>> share common code, make it a library.
> > >>>
> > >> I disagree.  Currently there are about 150 raster and 65 vector modules.
> > >> The list is not shrinking and becoming a bit unwieldy.
> > >>
> > >
> > > I don't see a problem with having a large number of modules.
> > >
> > >
> > >From a user's perspective this can become very confusing.
> > I tried to introduce the "keywords" concept to make the user easier
> > navigate through the available algorithms, but didn't get much
> > feedback on this.
> >
> >
> > ls -l $HOME/grass63/dist.x86_64-unknown-linux-gnu/bin | wc -l
> > 321
> >
> > plus scripts is already too much in my opinion.
> >
>
> The pain is eased by the hierarchical naming conventions, i.e. r.*,
> r.li.*, v.net.* and so on. However, it is paramount to adhere to those
> naming conventions. If the modules do have descriptive names arranged in a
> meaningful hierarchy it's not all that hard to find what you're looking
> for.

I agree.

>From a users perspective, there isn´t much difference between

i.ortho.photo cmd=foo

and

i.ortho.photo.foo

If one of the readline completion thingies is included in the
distribution by default, the latter is tab-searchable and respecting
the "namespaces" introduced by the naming convention is enough to
grant CLI users a good expereience.

As for docs, it could be good to have a main "introductory" page for
the general intent of each command from the "namespace" (in the same
spirit as sql.html and the like) referencing each commands specific
documentation (and linking back). I agree this is a little cumbersome
for maintenance.

As for GUI, I'm not qualified to commente, but my guess is that the
new option-depending-on-option proposal needs some adjustments/
refactoring for the GUI code.

As for code, well, we're talking about using (almost) the same
codebase with several commands in the PGM var of the Makefile, and
shred linking to core functions if any. Of course duplicated code is
to be avoided, but my guess is that librarizing the common functions
and using static linking (I would reserve dynamic for functions
reusable across several modules), there wouldn't be much difference.
Further, disentangling code that is meant to cover several special
cases usually simplifies it, which helps maintenability.

My PEN0.005 (about EUR0.02)

Daniel.

-- 
-- Daniel Calvelo Aros