[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gnulib-tool-py] Modules and avoids: migrate to GNULibMode class
From: |
Bruno Haible |
Subject: |
Re: [gnulib-tool-py] Modules and avoids: migrate to GNULibMode class |
Date: |
Fri, 22 Jun 2012 02:24:18 +0200 |
User-agent: |
KMail/4.7.4 (Linux/3.1.10-1.9-desktop; KDE/4.7.4; x86_64; ; ) |
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
- [gnulib-tool-py] Modules and avoids: migrate to GNULibMode class, Dmitriy Selyutin, 2012/06/21
- Re: [gnulib-tool-py] Modules and avoids: migrate to GNULibMode class,
Bruno Haible <=
- Re: [gnulib-tool-py] Modules and avoids: migrate to GNULibMode class, Dmitriy Selyutin, 2012/06/22
- Re: [gnulib-tool-py] Modules and avoids: migrate to GNULibMode class, Bruno Haible, 2012/06/23
- Re: [gnulib-tool-py] Modules and avoids: migrate to GNULibMode class, Dmitriy Selyutin, 2012/06/23
- Re: [gnulib-tool-py] Modules and avoids: migrate to GNULibMode class, Dmitriy Selyutin, 2012/06/23
- Re: [gnulib-tool-py] Modules and avoids: migrate to GNULibMode class, Bruno Haible, 2012/06/23
- Re: [gnulib-tool-py] Modules and avoids: migrate to GNULibMode class, Dmitriy Selyutin, 2012/06/23
- Re: [gnulib-tool-py] GLFileSystem, Bruno Haible, 2012/06/24
- Re: [gnulib-tool-py] GLModule or GLModuleSystem class, Bruno Haible, 2012/06/24
- Re: [gnulib-tool-py] GLModule or GLModuleSystem class, Dmitriy Selyutin, 2012/06/24
- Re: [gnulib-tool-py] GLModule or GLModuleSystem class, Bruno Haible, 2012/06/24