🚀 go-pugleaf

In article <5143@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
>The problem is *not* one of establishing new "modules" or new "namespaces"
>(which class declarations can do quite well, thank you).

Except that as you point out later on in your message, there is
currently no way to wrap a class declaration around a group of
top-level declarations and have them be treated as static members by
default.  So it seems to me that until some syntax is defined for that
purpose, this is still the primary problem, since as things stand
there's no way to resolve name conflicts at all (without editing the
source, which is exactly what I'm trying to avoid).

>							   No.  The problem
>is that if you do this, it becomes quite cumbersome to *reference* the
>things whose declarations you have now nested within class declarations.
>Specifically, it is quite irritating to have to write out the extra
>CLASSNAME:: qualification all over the place.
>
>How can this problem (i.e. the *real* problem) be solved?

Though I'm not opposed to an attempt to solve this problem in some
such way as you suggest, I think you overrate it.  I've worked on a
number of projects where the qualifiers were part of the names (i.e.
the language in use had no namespace facility at all), and therefore
they *always* had to be included, even in references from *inside* the
module.  Even so, it didn't particularly bother me, I guess partly
because the qualifiers made it easy to know what source file to look
in to find a definition.

>Recently, I proposed the introduction of a Pascal style `with' statement.
>Thinking more about it, I now realize that it would probably be better to
>have something more like an Ada `use' statement to solve this problem.

I agree that this would be handy.

>I think that if we had a `use' statement in C++, the problem of namespaces
>would be mostly solved.  Of course there would still be that irritating
>need to declare data and function members as `static'.  That's where having
>a `module <identifier> { ... }' construct would come in handy.  We could
>define a `module' to be just like a class except that its data members and
>function members would all be *implicitly* static.  Still, I'm sure that
>we're all against introducing new keywords if it could be avoided, so how
>about just using `class <identifier> static { ... }' rather than requiring
>`module <identifier>'.

Except it would presumably be `struct <identifier> static { ... }',
since it wouldn't do you much good if all the members were private!

Personally, I would prefer the introduction of a keyword in this case,
because it seems awfully strange to be using `struct' when I'm really
not declaring a structure.  Also, if there were also some sort of
`use' declaration, I think I would really want it to work only on
modules; otherwise its definition has to be that it makes the names of
only static members visible, because it wouldn't make sense to make
the names of normal (nonstatic) members visible, and I think that
would be weird.

-- Scott