Re: [gnulib-tool-py] Modules and avoids: migrate to GNULibMode class

[Bruno Haible]

Hi Dmitriy,

> there are two classes: GNULibMode and GNULibImport, where GNULibMode class
> is the parent for GNULibImport class. ...
> Don't you think it would be better to move *all* actions which operates
> with modules to GNULibMode parent class?

I wouldn't move all actions on modules to the superclass, only those
that need only the parameterization that is available to the superclass.

Look once again over the 'gnulib-tool --usage' output: There are some
operation modes that are influenced only by the general options
(--local-dir, --[no-]cache-modules, --verbose/--quiet):

  --list
  --find
  --extract-description
  ...
  --extract-tests-module
  --copy-file

This means, the Python functions that implement these operation modes
can sit in the superclass.

Whereas the operation modes --import, --add/remove-import, --create-testdir,
... - namely the modes which create files and directories on disk -
are influenced by a number of additional options (--dir, --with-tests,
--avoid, --libtool, and so on). So these belong in the subclass.

Maybe it will be necessary to create more subclasses; I don't know whether
you will want to handle --import, --add/remove-import in the same class as
--create-testdir. I would maybe create a class hierarchy like this:

          GnulibMode - elementary operations on modules (read-only)
              |
   GnulibChaffCutter - intermediate class for generating files based
   |               |             the contents of a list of modules
   |               |
GnulibImport  GnulibTestdir

because there is a significant amount of code that applies only to
--import, --add/remove-import and not to --create-testdir and vice versa.

How to call this intermediate class? GnulibChaffCutter? GnulibMill?
GnulibCombineHarvester? None of these doesn't sound right so far.

Bruno