<maxb@tigris.org> wrote in message
news:200407212231.i6LMVQ308385@morbius.ch.collab.net...
> Author: maxb
> Date: Wed Jul 21 17:31:26 2004
> New Revision: 10381
>
> Modified:
> trunk/build/generator/gen_base.py
> trunk/build/generator/gen_make.py
> trunk/build/generator/gen_win.py
> Log:
> Phase 1 of a series of refactorings of the build generator code, intended
to
> make it easier to understand the architecture of Target and Section
classes.
> ...
> class Target(DependencyNode):
> "A build target is a node in our dependency graph."
>
> - def __init__(self, name, options, cfg, extmap):
> + def __init__(self, name, options, gen_obj):
> self.name = name
> + self.gen_obj = gen_obj
I don't think targets should hold references to the generator object. The
generator is a singleton, there's only one instance of it created for the
entire program. It seems like a waste of space to create a bunch of target
objects that all point to the same generator.
All other target members contain information about the target itself, and
they are used by generor backends to generate build rules for the target.
But the gen_obj member contains no information specific to the target, and
it would never be used by any backend because backends can access the
generator singleton directly.
Hopefully, that argument makes some sense and is convincing. If not, I think
the "gen_obj" member should be renamed to "_generator." The leading
underscore is appropriate for a private member that is only used internally
by Target methods. And losing the "_obj" suffix isn't a big deal because it
tells little about how the member is used or what it means (I usually think
the same thing about "_var", "_int", "_string" suffixes when they aren't
there for disambiguation)
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 23 02:47:38 2004