Russell Yanofsky wrote:
> <email@example.com> wrote in message
>> Author: maxb
>> Date: Wed Jul 21 17:31:26 2004
>> New Revision: 10381
>> Phase 1 of a series of refactorings of the build generator code, intended
>> make it easier to understand the architecture of Target and Section
>> 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.
"waste of space"?
It seems sensible to me to give the Target objects a reference to the global
state of the generation process - the generator object.
> 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.
It's purpose is not to be used by the backends, but to be used by the Target
object during add_dependencies().
BTW, does anyone else find it bizarre that you have to construct a Target
object, and then manually call what is effectively a "more_init" function
before it is useful?
> Hopefully, that argument makes some sense and is convincing. If not, I
> the "gen_obj" member should be renamed to "_generator." The leading
> underscore is appropriate for a private member that is only used
> by Target methods. And losing the "_obj" suffix isn't a big deal because
> tells little about how the member is used or what it means (I usually
> the same thing about "_var", "_int", "_string" suffixes when they aren't
> there for disambiguation)
That, I agree with. It is a private member.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Jul 24 01:42:14 2004