[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r10381 - trunk/build/generator

From: Russell Yanofsky <rey4_at_columbia.edu>
Date: 2004-07-24 02:04:23 CEST

Max Bowsher wrote:
> Russell Yanofsky wrote:
>> 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"?

Space, i.e. memory. You are adding a new class member to store redundant
information.

> It seems sensible to me to give the Target objects a reference to the
> global state of the generation process - the generator object.

It is fine for target objects to get a reference to the generator object. We
can pass it as a parameter to any methods that need it. What I object to is
storing the reference as part of the state of Target objects because it
contains redudant information that isn't specific to any target.

>> 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().

If it needs to be used by add_dependencies, then it should be passed as a
parameter to 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?

Yes. It'd be good either merge the __init__ and add_dependencies methods or
else have the __init__ method invoke the add_dependencies method.

- Russ

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 24 02:05:17 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.