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

From: Pedro Ferreira (pedro.ferreira_at_[hidden])
Date: 2005-01-25 08:46:28

Em 25 Jan 2005, =E0s 07:33, Vladimir Prus escreveu:

>
> 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=20
> Jamfiles
> and then call bjam for loading and parsing a Jamfile. The rule=20
> invocations in
> that Jamfile will be forwarded back to PyBB.

Yes, that's my idea.

>>> I agree that global variables are not, in general, a problem for=20
>>> 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 ;-)

I see you are lucky enough not to have to deal with legacy code ;-)

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

Right. I definitely agree that it is not a good solution but it is a=20
goal not to redesign at this point.

>>> - 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=20
> access to the
> list of types, features and generators, it's convenient to have a=20
> class which
> just stores all that. It's not meant to be abstraction, it's just a=20
> bag of
> data.

Ditto.

>>> - stand alone modules that declare targets and features need access=20
>>> 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=20
> without
> interfering with anything.

And only while we don't have things solid enough so we can redesign it.

>>> , e.g. the ones in tools and tool/types:
>>
>> Those modules are "stand alone?" In what sense?

Bad wording. I meant that, when they are loaded, global variables are=20
'automagically' set.

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

Consider tools/types/cpp.jam. With BBv2, when you import this module=20
the type 'CPP' is added to the global list of types.
Without global variables, you need to pass a context to the cpp.jam=20
counterpart in PyBB.
My proposal is to implement a function along the lines of:

def importXXX (manager, module_name):

import_the_module (module_name)
if has_register_function (module_name):
call_register_function (manager, module_name)

Then Tools/Types/Cpp.py would be:

def register (manager):
manager.types ().type ('CPP', ['cpp', 'cxx', 'cc'])

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

I'm glad that you are less worried and hope you are less confused now=20
:-)

Regards,

Pedro
 --Apple-Mail-1--495429901 Content-Transfer-Encoding: quoted-printable
Content-Type: text/enriched;
charset=ISO-8859-1

Em 25 Jan 2005, =E0s 07:33, Vladimir Prus escreveu:

<excerpt>

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

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

</excerpt>

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

</excerpt>

I suppose PyBB will compose a list of rules which are available for
Jamfiles=20

and then call bjam for loading and parsing a Jamfile. The rule
invocations in

that Jamfile will be forwarded back to PyBB.

</excerpt>

Yes, that's my idea.

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

</excerpt>

It's been a long time since I've been so bitten, but then I tend to

avoid globals ;-)

</excerpt></excerpt>

I see you are lucky enough not to have to deal with legacy code ;-)

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

</excerpt>

This sounds like it might be insufficiently abstracted. A class

usually shouldn't just be a pile of variables, and...

</excerpt>

That's true, but=20

(i) the variables won't be accessible via get/set

(ii) making better abstraction is redesign, which we try to avoid.

</excerpt>

Right. I definitely agree that it is not a good solution but it is a
goal not to redesign at this point.

<excerpt><excerpt><excerpt>- having to carry around a Manager

</excerpt>

...right there, the fact that you're calling this thing a "manager" is

possibly a good indication of that insufficient abstraction.

</excerpt>

This might be not so bad. After all, if all modules want to have
access to the=20

list of types, features and generators, it's convenient to have a
class which=20

just stores all that. It's not meant to be abstraction, it's just a
bag of=20

data.

</excerpt>

Ditto.

<excerpt><excerpt><excerpt>- stand alone modules that declare targets
and features need access to

the current Manager

</excerpt>

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

</excerpt>

There's one global variable. You still can freely test all modules
without=20

interfering with anything.

</excerpt>

And only while we don't have things solid enough so we can redesign it.

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

</excerpt>

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

</excerpt></excerpt>

Bad wording. I meant that, when they are loaded, global variables are
'automagically' set.

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

</excerpt>

I can't picture what you're describing.

</excerpt></excerpt>

Consider tools/types/cpp.jam. With BBv2, when you import this module
the type 'CPP' is added to the global list of types.

Without global variables, you need to pass a context to the cpp.jam
counterpart in PyBB.

My proposal is to implement a function along the lines of:

def importXXX (manager, module_name):

import_the_module (module_name)

if has_register_function (module_name):

call_register_function (manager, module_name)

Then Tools/Types/Cpp.py would be:

def register (manager):

manager.types ().type ('CPP', ['cpp', 'cxx', 'cc'])

<fixed><x-tad-bigger>

</x-tad-bigger></fixed>

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

</excerpt></excerpt>

I'm glad that you are less worried and hope you are less confused now
:-)

Regards,

Pedro

 --Apple-Mail-1--495429901--