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

From: Pedro Ferreira (pedro.ferreira_at_[hidden])
Date: 2005-01-25 10:59:20

David Abrahams wrote:

>>>>>, 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 
>>'automagically' set.
>>
>
>I still don't understand. Plus, I've lost the context. Can you
>rephrase the whole statement and explain?
>

In BBv2, modules that declare targets and features (e.g. the ones in tools and tool/types) need no context to do their job, for they operate on global variables.
In PyBB, not having global variables, they need access to a Manager object. That is why I proposed what is below.

>>>>>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 
>>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)
>>
>
>Hm. This doesn't make too much sense to me. After all, modules can
>only be loaded once. Once they are loaded, their "globals" (really
>module-local variables) have to be set. 
>

What about:

def importXXX (manager, module_name):

if not imported (module_name):
import_the_module (module_name)

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

> I'm feeling doubtful again
>about the wisdom of subverting this model, especially because it fits
>so well into Python's model for bindings in a module.
>

I'm with when you mention ease of use. By all means, it's easier to use 
globals. Then again, I think it's cleaner not to and am very worried 
that if we go down that path we'll regret it.
More advice please.

>>Then Tools/Types/Cpp.py would be:
>>
>
>Please, can we have all_lowercase module names?!
>
Sure, but that definitely is religious :-)
What about class names and file names?

>>def register (manager):
>> manager.types ().type ('CPP', ['cpp', 'cxx', 'cc'])
>>
>
>Looks icky to me. 
>

Sure it sould be simpler to do

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

but I'm ready to trade neatness for security.
Still, I agree with you that globals for types, features and similar are 
not showstoppers (bar the testability) but I feel uncomfortable about 
that. What do you think?

>BTW, I know this is probably a religious issue, but space separating
>function names from argument lists makes them hard to read because you
>can't visually "grep for [a-z](" to find all calls.
>
It is religious but I don't have a problem with that. I'll try.
BTW, what's the general feeling about that?

Pedro