Re: [gnulib-tool-py] GLFileSystem

[Bruno Haible]

Hi Dmitriy,

> 1). GLFileSystem(GLMode): func_lookup_file. It has one argument:
> localdir. It also uses DIRS['root'] constant. In __init__ it
> calculates the path of the original or patched file and saves it as
> attribute of this class (e.g. GLFileSystem.path). May be we could add
> something here? I really dislike an idea to create class for only one
> action, but it is even more ugly to create function when we've decided
> to use classes everywhere.

The question is whether it is better
  - to have a class with 1 instance, with methods that take a file name
    as arguments,
  - or to have a class with many instances, one instance per file name,
    and methods that take no arguments,
  - or maybe even both.

Both approaches are good OO design. And you can make one choice for one
class and the opposite choice for another class; this is not a problem and
not ugly. Only the 3rd choice is to be made only when needed, otherwise
it's overkill to create two classes that are so much tied together.

The choice is mostly based on the semantics and the available operations.

In the sketch I made in
http://lists.gnu.org/archive/html/gnulib-tool-py/2012-06/msg00005
the semantics is: Given the gnulib root directory and an optional
--local-dir value, we have an entity with 3 methods:
  - A method to return the contents of a file with given name
    (func_lookup_file).
  - A method to list/enumerate all subdirectories of a given directory.
  - A methid to list/enumerate all files (recursively) of a given directory.
To me this clearly points to the first choice, a class with 1 instance.

The method func_lookup_file is only one of the methods. To create a class
that represents its result (and which will have one instance per file name)
is possible, but overkill in my opinion.

Bruno