On Mon, Jul 7, 2014 at 10:24 PM, Kim Gräsman <[email protected]> wrote:
> > It seems to me the way forward is to attack the circular dependencies > head-on on a couple of fronts: > - command-process-jobs can be split up into independent parts by > moving job-related stuff to new jobs module and moving > call/call_native from process to command > - all exceptions can be safely moved into an pymake.errors module, > which reduces irrelevant dependencies on data, parser and process > - parserdata.Location and parser.Data have no outgoing dependencies > and can be moved to their own module (e.g. pymake.values) > - the SOURCE_ and FLAVOR_ flags seem to be used from a number of > places and might make sense in the same module, to disassociate them > from the heavy data module > I've spent some time experimenting with these, and it clears up some of the circularity. Unfortunately, far from all of it. The data, parserdata, parser and functions modules all have two-way dependencies between each other. > - speculative: I think functions.py could be split up so that each > module (data, parser, ...?) can contribute functions that operate on > structures they supervise. E.g. data would provide SubstitutionRef > because it depends on data.Pattern; parser would provide EvalFunction > because it depends on parser.parsestring. Etc. Someone > (pymake.command?) would need to orchestrate the building of the > function map and pass it to parser, which seems to be the only user. > But I think this idea has merit. In fact, the recurring dependency patterns I see are; - use of a type name for assertion (e.g. assert isinstance(data.Expansion)) - use of a type name for instantiation (e.g. parser.Data(..., parserdata.Location(...))) - function calls (e.g. parser.parsemakesyntax(...)) The first two can be mitigated by creating a pymake.model module containing all classes representing Make concepts (e.g. parser.Data, parserdata.Location, functions.Function and some derivatives, data.Makefile, some of the data.Expansion hierarchy). It seems to me very little work would be necessary to make them mostly independent of their surrounding code, especially if they were all in the same module (they have lots of interdependencies.) As suggested in the quote above, all classes that _do_ have special needs (e.g. EvalFunction, Variables.append, etc) should stay close to their dependency as a subclass of the concept class in pymake.model and with some kind of dynamic registration mechanism. The actual, concrete function calls between modules are the real killers. They would either need to be fixed with dependency injection (callback arguments), moving functions closer to their use or using your suggested hacks. I'm going to experiment with this to get an idea of feasibility, and then I can suggest an incremental way forward. Sound OK? - Kim
_______________________________________________ dev-builds mailing list [email protected] https://lists.mozilla.org/listinfo/dev-builds
