Re: [jamboost] Re: Native rules proposal

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-12-15 01:30:16

David Abrahams wrote:

> >> The problem with builtins is that they are declared and executed in
> >> global module. This means that if rule accesses module variables, or if
> >> rule is a class method, we're in trouble, since those variables can't be
> >> accessed, at least cleanly.
> >
> > Isn't that what the "localize" parameter to IMPORT is for?
>
> Volodya, I don't mean to press you, but I'm afraid that large and
> unneccessary changes could get made if you don't consider this
> question.

Sure. I did asked about the proposal precisely to make sure this is not a 
mistake. I was not able to reply on Friday because we had yet another holiday 
here in Russia.

Now about 'localize' -- I did not consider it at the moment. IIUC, with 
'localize', the whole thing will work like:

1. You declare builtin called 'set.difference'. 
2. Insides the 'set' module, you put

IMPORT : set.difference : $(_name) : difference : localize ;
EXPORT set : difference ;

3. After 'set.jam' is read, the 'difference' rule is exported into global 
scope, and now 'set.difference' behaves as rule declared in 'set', but is in 
fact implemented in 'C'

The good thing about the proposal is that it does not require a new builtin. 
The only thing I don't like is cluttering the global namespace. 
After all, the implementation -- the .c files declaring new rules -- is better 
live in separate files in 'modules' directory, as builtins.c is large enough 
already. It's nicer if namespaces follow that layout, though it's not 
critical.

- Volodya