Re: RFC: Proposal to port BBv2 to Python

From: David Abrahams (dave_at_[hidden])
Date: 2005-01-24 17:05:49

Pedro Ferreira <pedro.ferreira_at_[hidden]> writes:

>> this looks like a complete rearchitecture of Boost.Build, which casts
>> aside much valuable design work.
>
> No, that was not my intent. What I meant here is that the concept of 
> having projects stored in files needs not be embedded in the core. 

Oh, that's fine then.

> I didn't mean to dismiss the concept of a project at all. My idea
> was to delegate that to the parser - e.g. bjam parser - which could
> be signalled by the core that the project at a certain location
> needs to be loaded. 

I'm sorry; what, specifically, would be delegated to the parser?

> Still, at least at the initial phase of porting, I have no strong
> feelings against this.
>
>
>> That makes me very worried and much less inclined to support the 
>> effort.
>
>
> Please bear in mind that I sent a request for comments. I just 
> collected a bunch of ideas into what I thought was a reasonable 
> strawman proposal for this work. I didn't mean it to be definitive, nor 
> do I want do all this by myself: I just want (need) this to be working 
> as soon as possible, so I am willing to collaborate with and support 
> the effort of anyone who has better or more appropriate ideas.

That's good.

>> I don't think it's neccessary to prohibit global variables for things
>> like type registrations. There are many reasons it's reasonable to
>> assume that type registration needn't interfere with concurrent
>> launching of build tasks. That just seems like it could be a huge
>> complication for little or no gain.
>
>
> I agree that global variables are not, in general, a problem for types 
> and similar things. They even have some advantages, e.g. for 
> registering types automatically, like it is done in BBv2, just by 
> importing a file.
> Still, I have strong feelings against globals in general - I'm sure 
> we've all been bitten by them more often than not - and that's why I 
> proposed it as I did.

It's been a long time since I've been so bitten, but then I tend to
avoid globals ;-)

> Plus, it simplifies testing, as you don't need to clear global 
> variables to see if things are working and, if it turns out that it is 
> indeed necessary to make these non-global, it will be way more 
> difficult to do it afterwards.

That's a good point.

> As for the complications you suggest, I see them in three aspects:
>
> - in the porting itself: creating a class for holding the per module 
> globals basically boils down to add a class declaration and indent all 
> the code. This pushes all variables and methods into that class;

This sounds like it might be insufficiently abstracted. A class
usually shouldn't just be a pile of variables, and...

> - having to carry around a Manager 

...right there, the fact that you're calling this thing a "manager" is
possibly a good indication of that insufficient abstraction.

> object (which contains an instance of the TypeRegistry): this is
> sometimes a pain. Still, the manager is needed for most anything I
> think we agree cannot be global, so it will be needed anyway;
>
> - stand alone modules that declare targets and features need access to 
> the current Manager

Once there's a "current" Manager you have globals again.

> , e.g. the ones in tools and tool/types: 

Those modules are "stand alone?" In what sense?

> we can move 
> the code in those modules into a function with a well-known name, say 
> 'register', which receives a Manager instance as a parameter. 

I can't picture what you're describing.

> The core could load the module, check if there is such a function,
> and call it with the appropriate Manager instance.
>
> Looking forward to your comments!

I'm very confused, but less worried than I was.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com