Dirk Bächle wrote:
What happens now and then is, that users are unhappy with the way this Taskmaster proceeds. One peculiar detail is, that our "default" Taskmaster always deletes the old target file before re-building it...and in special situations this may be seen as unwanted.
I'm not convinced that replacing the Taskmaster for the entire build is the right way to address this kind of thing. What if you want to override that behaviour for some targets but not others? A single object that controls behaviour globally makes things inflexible. (Distutils suffers from this problem with its "command classes" that can only be overridden in their entirety or not at all.) It seems to me that it would be better for the Taskmaster to delegate as much behaviour to the Nodes as it can, and provide a way of designating which Node classes to use for particular targets. I'd even suggest that *all* of the build logic should be in the Nodes, and the Taskmaster class shouldn't exist at all. The top level logic should just tell the final Nodes to bring themselves up to date, and they recursively do likewise for their dependent nodes.
I'm currently following the "Factory" pattern (more or less) as I know it from C++ and similar languages.
This statement sets off alarm bells for me. If you're using some design pattern in Python just because you learned to do it that way in C++/Java/whatever, you're probably making it more complicated than it needs to be. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
