Re: Native rules proposal

From: David Abrahams (dave_at_[hidden])
Date: 2003-12-17 15:01:00

Vladimir Prus <ghost_at_[hidden]> writes:

> David Abrahams wrote:
>
>> > 1. You declare builtin called 'set.difference'.
>>
>> You could call it anything.
>>
>> > 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'
>>
>> Yep.
>>
>> > The good thing about the proposal is that it does not require a new
>> > builtin.
>>
>> You mean _my_ proposal?
>
> Yes.
>
>> > 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.
>>
>> It should be very easy to get builtin rule declarations to go into a
>> specific module. You could even do it by searching for "." in the
>> name.
>
> Interesting. In this case one would not need the IMPORT/EXPORT stuff at all, 
> right? 

Well, not for this case.

> But then the only difference with my proposal is that builtin is added 
> to module immediately, whereas for my approach they are hidden unless you 
> call 'NATIVE_RULE'. This allows to leave the original definition of the rule 
> there and just add NATIVE_RULE call after it -- i.e. you can easily switch 
> between C and jam implementation. 

Why does it matter which one replaces the other?
You can always replace the C implementation with the jam one later.

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