Re: [gnulib-tool-py] GLModule or GLModuleSystem class

[Bruno Haible]

Dmitriy Selyutin wrote:
> 2). GLModuleSystem(GLMode): I'm completely confused between
> GLModuleList, GLModule and GLModuleSystem classes. What this class
> shall do?

If there is no class GLModule, then GLModuleSystem is the class which
shall implement the operations
     func_exists_module (name)
     func_verify_module (name)
     func_verify_nontests_module (name)
     func_verify_tests_module (name)
     func_get_description (name)
     func_get_comment (name)
     func_get_status (name)
     func_get_notice (name)
     func_get_applicability (name)
     func_get_filelist (name)
     func_filter_filelist (filelist, prefix, suffix, ...)
     func_get_dependencies (name)
     func_get_autoconf_early_snippet (name)
     func_get_autoconf_snippet (name)
     func_get_automake_snippet_conditional (name)
     func_get_automake_snippet_unconditional (name)
     func_get_automake_snippet (name)
     func_get_include_directive (name)
     func_get_link_directive (name)
     func_get_license_raw (name)
     func_get_license (name)
     func_get_maintainer (name)
and have the fields:
  localdir, verbose, modcache

If there is a class GLModule, then func_verify_module is part of its
constructor (__init__ function), as you have explained, and GLModule
contains the operations
     func_get_description ()
     func_get_comment ()
     func_get_status ()
     func_get_notice ()
     func_get_applicability ()
     func_get_filelist ()
     func_get_dependencies ()
     func_get_autoconf_early_snippet ()
     func_get_autoconf_snippet ()
     func_get_automake_snippet_conditional ()
     func_get_automake_snippet_unconditional ()
     func_get_automake_snippet ()
     func_get_include_directive ()
     func_get_link_directive ()
     func_get_license_raw ()
     func_get_license ()
     func_get_maintainer ()
But the class GLModuleSystem is also needed, because it is needed to
store the modcache field. Also, maybe it can have the operation
     func_exists_module (name)
that GLModule.__init__ is relying on.

The class GLModuleList assumes the specification of an --avoid list.
and does operations on a list of modules.

> 3). GLModule(object?). It has arguments: module, localdir,
> macro_prefix (something else?).

module name: yes.
localdir: ok but I would prefer if it be a GLFileSystem instance (see
the other mail).
macro_prefix: no. GLModule should be an entity that makes only read-only
accesses to the file system. The macro_prefix occurs only in relation
with a destdir and the GLGenerator. IMO everything that needs a macro_prefix
belongs in the class GLGenerator or its subclasses.

> When we need to iterate through list of
> modules we can use such construction:
> 
> modulelist = [GLModule for module in ['yesno', 'xsize', 'xsublist']]
> 
> That will return a list of GLModule instances. Then we can do what we
> want, e.g. print maintainer for each module:
> 
> for module in modulelist:
>   print(module.getMaintainer())

Good. But for storing the --avoid list and --with[out]-tests, --with-obsolete
parameters that are needed for the equivalent of func_modules_transitive_closure
we need a class GLModuleList, no?

> And the last (see 2). too): where we will place getAllModules method?
> May be GLInfo will be good for this aim?

GLInfo? Certainly not. getAllModules relies on the GLFileSystem (or the
--local-dir option) and knows about the module structure, therefore a
natural place would be the class GLModuleSystem.

Bruno