Re: [jamboost] Progress on issue 578618: Leave jamfile modules for user.

From: Rene Rivera (grafik666_at_[hidden])
Date: 2002-08-05 11:01:24

[2002-07-08] Vladimir Prus wrote:

>David Abrahams wrote:
>
>> > modules. First is "__attributes__" variable, which keeps an instance of
>> > "project-attributes" class. Second is the convernience method
>> > "__attribute__", which allows to write
>> >
>> > local p = <some jamfile module> ;
>> > local requirements = [ $(p).__attribute__ requirements ] ;
>> >
>> > instead of
>> >
>> > local p = <some jamfile module> ;
>> > local attr = [ modules.peek $(p) : __attributes__ ] ;
>> > local requirements [ $(attr).get requirements ] ;
>> >
>> > I think this amount of namespace pollution is perfectly acceptable.
>>
>> Acceptable, but also (I think) unneccessary. Assuming you have a module
to
>> work with (e.g. jamfile.jam), you could store the __attributes__ for a
>> given jamfile in $(jamfile-name).__attributes__ in that module. You could
>> also implement a jamfile.get-attribute ( jamfile attribute) rule which
>> extracts the value of a given attribute for a particular jamfile.
>
>That would be more verbose, and the question is by how much? I'm about to 
>look at all uses of "__attribute__" to settle that question.

While having to implement the same thing for project-root I came up with a
somewhat less anoying syntax for these uses. Instead of having to get the
object, then make calls on the object. I just pass along what call I want to
make to the single access function and it makes the call. For project root
one use looks like:

ECHO [ project-root get-location ] ;

It sould replace the above with:

local requirements = [ project.attribute get requirements ] ;

(or something like that)

Thoughts?

-- grafik - Don't Assume Anything
-- rrivera_at_[hidden] - grafik_at_[hidden]
-- 102708583_at_icq - Grafik666_at_AIM - Grafik_at_[hidden]