2012/6/23 Dmitriy Selyutin
<address@hidden>
Hi Bruno,
I've read all what you say and I'm absolutely agree with you. The main idea is great. Still I have to say:
1) Some module names are too long and too cryptic at the same time. The second problem can be solved in the docstrings, but the first is a real headache. It conflicts with Zen of Python (to read it type in interpreter: import this).
2) Even if we rename some classes, we have to change their behaviour.
> class GNULibReadOnlyOperations
Here is my proposal how to change this class.
We create new class GNULibModule, which inherits GNULibMode. This class has only one additional argument in __init__: module name. When we create new GNULibModule instance, it checks module (analogue of the func_verify_module) and if all is great it creates instance.
Inside GNULibModule it we have all methods which need only methods which need basic attributes from GNULibMode and the name of the package. To get the type of the module, we simply use methods. Here is an example:
module = GNULibModule(destdir, localdir, name)
module.isTest() # returns True or False
module.getDescription() # returns description of the module
module.get*() # returns * of the module
It seems we don't need to verify module using func_verify_module, because it is already checked when user creates GNULibModule instance. I suppose we only have to check module in __init__ part and catch GNULibError #3 if we need.
And I suggest to rewrite addModule, addAvoid, setModules, setAvoids, etc. to accept instances of the GNULibModule instead of strings.
As for func_lookup_file, it is done where it is needed (in our case GNULibImport class) and returns correct module names, from which we then create GNULibModule instances.
I think that such name and function would be better for this class. What do you think?
> class GNULibModuleListOperations
All is right, however, I suggest to cut name to GNULibModuleList. I think that it must inherit not from GNULibModule, but from GNULibMode since GNULibModuleList has nothing common with GNULibModule class.
func_acceptable will be deprecated since it just tests whether module is in the self.args['avoids'] list. We don't need function for this, because we can just use such construction: return(module in self.args['avoids']). It returns True or False. That's pretty enough.
func_get_tests_module will be deprecated too, since we have just to use something like this:
try: # Try to create testsmodule for module
testsmodule = GNULibModule(destdir, localdir, module)
except GNULibError as error:
if error.errno == 3:
print('There is no tests module for module %s' % error.errinfo)
As for func_module_shellfunc_name, func_module_shellvar_name, func_module_conditional_name and similar functions, where each function needs only module name... I think that it fits best to GNULibModule: we just have to create methods for each such function.
As for func_cond, I need your help since it is hard to understand what is done here (I think the concept will be enough).
>
3) class GNULibGenerator
I think here everything is good here, however, I have to think about it more when I begin to write code for this part.
Everything other is great, I think. How do you think, wouldn't it be better to change names of the classes from GNULib* to GL*?