bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Refactoring rewrite_filename functions


From: Collin Funk
Subject: Re: Refactoring rewrite_filename functions
Date: Tue, 16 Apr 2024 19:08:10 -0700
User-agent: Mozilla Thunderbird

On 4/16/24 6:35 PM, Bruno Haible wrote:
> This does not make sense. GLConfig is meant to hold settings and 
> configuration,
> nothing more.
> 
> I see the home of this function more in GLFileSystem.py. Maybe in class
> GLFileAssistant, maybe in a new class in that same file.

Hmm, thanks for the advice. At the moment I think GLFileAssistant
makes sense. Since it performs transformations on the files based on
their categories, transforming the path names seems somewhat in its
domain.

This will require some code reordering first though. The
GLFileAssistant used by GLImport is not defined until
GLImport.execute(). The file name transformations are done in
GLImport.prepare(). This function also returns the transformers used
by GLFileAssistant.__init__().

I think the correct solution there is to define the GLFileAssistant in
GLImport.__init__() with it's default arguments and then set them
later. I've been meaning to do this anyways because I find defining
things outside of __init__ makes things harder to follow. This was
also a reason I had in the back of my head when fixing the default
arguments here:

    https://lists.gnu.org/archive/html/bug-gnulib/2024-04/msg00228.html

> 'tests=lib/' should not occur in the scope of mode == 'copy-file'.
> But this string is an indicator inside gnulib-tool; users of gnulib-tool
> should not be allowed to pass it.

Okay I see. I'll leave it as-is now since it works and I rather not do
accidental replacements. :)

Collin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]