Re: [jamboost] projects.jam

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
>such
>> > a hot idea. I started that for the "modules" module because that bit
>of
>> > 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,
>maybe
>> > I'm mistaken. It's hard to tell without seeing more of what's going
>on.
>>
>> We'll still need an ability to decorate module variables when there
>are
>> 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
>not
>> 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
>code.

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
>function
>> > comments at the top of the file. When I get to a new function I have
>to
>> > skip back up to look for a comment.
>>
>> I've used this style to present module interface at the top, so that
>client
>> don't have to scroll over function definition. Perphaps I just should
>start
>> 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]