Boost logo

Boost-Build :

From: Rene Rivera (grafik666_at_[hidden])
Date: 2002-04-09 19:43:20

On 2002-04-09 at 09:17 AM, david.abrahams_at_[hidden] (David Abrahams) wrote:

>----- Original Message -----
>From: "Vladimir Prus" <ghost_at_[hidden]>
>> I have changed this.
>> > I'm not sure that defining all of those variables as __<name>__ is
>> > a hot idea. I started that for the "modules" module because that bit
>> > jam code is practically a part of the core system, and I wanted to
>> > emphasize that these names were a part of that mechanism. However,
>> > I'm mistaken. It's hard to tell without seeing more of what's going
>> We'll still need an ability to decorate module variables when there
>> accessor rules for them. Maybe "m_" prefix is not such a bad idea?
>Actually we don't: they could be named the same as the rules, FWIW.
>Anyway, the convention that Rene and I have settled on (I think) is that
>names with dots in them are intended (module) globals, so
>rule location ( )
> return $(.location) ;

I remember that. But I don't think we entirely settled it for
psuedo-function vars.

I know we leaned towards xxx.yyy, but there is currently one use which
doesn't seem to fit that. For the name of the module of Jamfiles, and
project-root, where we need to decorate with a path using the xx.yyy style
is ugly :-\ Vladimir is currently using xxx_at_path, and I've tried both that
and xxx<path>. Opinions?

>> I always had the opinion that braces style is not important -- I have
>> problems reading either one, and fingers are less flexible than eyes.
>> If you find reading my style to be hard, I'll try to change it.
>It's not that so much that I find it hard to read (though I guess I'm
>more sensitive to such issues than most people), but that I'm afraid
>we'll make a mess if we don't try to use the same style in all of the

I've actually found the braces style important, FWIW. I like having the
openning brace line up vertically with the closing brace.

>> > It would help me in reviewing the code if you didn't put all
>> > comments at the top of the file. When I get to a new function I have
>> > skip back up to look for a comment.
>> I've used this style to present module interface at the top, so that
>> don't have to scroll over function definition. Perphaps I just should
>> using doc module.
>Your reasoning makes sense to me, but I hope that the doc module will
>eventually make that issue go away.

I've always tended to put the most public interface at the top of the scope,
this true for any language I write in. In this case having the
implementation along with it impeeds the readability, but not by much. Maybe
we should just apply a concerted effort to make those public interface rules
very short!

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


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at