Re: [jamboost] Re: RFC: Proposal to port BBv2 to Python

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-01-25 02:33:45

On Tuesday 25 January 2005 01:05, David Abrahams wrote:

> > 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?

I suppose PyBB will compose a list of rules which are available for Jamfiles 
and then call bjam for loading and parsing a Jamfile. The rule invocations in
that Jamfile will be forwarded back to PyBB.

> > 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 ;-)

For example, the trick feature.jam uses to do unit testing is well, tricky.

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

That's true, but 
(i) the variables won't be accessible via get/set
(ii) making better abstraction is redesign, which we try to avoid.

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

This might be not so bad. After all, if all modules want to have access to the 
list of types, features and generators, it's convenient to have a class which 
just stores all that. It's not meant to be abstraction, it's just a bag of 
data.

> > - stand alone modules that declare targets and features need access to
> > the current Manager
>
> Once there's a "current" Manager you have globals again.

There's one global variable. You still can freely test all modules without 
interfering with anything.

- Volodya