Boost logo

Boost-Build :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-04-09 20:11:39


----- Original Message -----
From: "Rene Rivera" <grafik666_at_[hidden]>

> >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

Within the module itself, I am willing to use __name__ which is what
modules.jam does. But that's not a pseudo-function. Are you talking
about a variable in some other scope?

>, and
> project-root, where we need to decorate with a path using the xx.yyy
style
> is ugly :-\

Sorry, I'm lost; could you be more explicit?

> Vladimir is currently using xxx_at_path, and I've tried both that
> and xxx<path>. Opinions?

Is xxx_at_path actually a variable name? We've been using that syntax to
denote project and target ids...

...

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

Sorry, Vladimir, it looks like unaligned braces lose the vote.

> >> 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!

Discipline is always good.

-D

 


Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk