Re: [jamboost] Boost.Build V2, load behaviour part 2.

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-03-30 22:06:23

Further, looking at our code, I think I'd like to change our coding
conventions a little. When code gets too uniform, it gets hard to read
(which is why I don't do all my coding in common lisp). In particular, I
think my choice to use "function.parameter" for pseudo-function
variables may have been a mistake. Since Jam doesn't require any
parentheses or similar marks to distinguish rule invocations, it can be
hard to tell them from literal strings. Also, I think distinguishing
local variables from those intended to be module globals could be an
advantage in light of Jam's dynamic scoping. Let's have a (very) short
round of brainstorming on this and come to a new decision.

Summary:

Pseudo-function variables:

$(foo($(bar),$(baz))) - too many parens
$(foo.$(bar).$(baz)) - too much like other things
$(foo[$(bar)]) - possible collision with $(foo[3])
still too many parens
$(foo<$(bar),$(baz)>) - scary, but visually superior?
confusable with grist
$(foo:$(bar),$(baz)) - minimalist

Regular Variables:

$(this-and-that) - they all look alike; locals may
collide with intended globals
Rule names:

tea-for-two - Haven't we met somewhere before?

I note that pseudo-function variables are pretty much always intended
globals, for what that's worth. I like working mostly with lower case
and dash separators, but maybe intended globals should use
Initial-uppercase or something. I note that class data members are also
intended globals, though they are used much differently.. Perhaps
m_whatever makes sense. I'm definitely open to suggestions here.

-Dave

----- Original Message -----
From: "David Abrahams" <david.abrahams_at_[hidden]>

> Hooray!
>
> Question: what is a "module-tag" supposed to be?
>
> After you answer that question, could you please update the docs for
> modules.load to describe exactly what the parameters mean?
>
> Thanks,
> Dave