How do namespace scope and class scope differ?

[Steven T. Hatton]

It was once suggested to me that I could accomplish much the same thing that
modules would accomplish (if C++ had modules) by writing my entire program
- except for main() - inside of a class. When it was suggested, I didn't
take it very seriously, but I have recently begun wondering if it is an
idea worth considering. I'm now trying to think of what fundamental
differences might exist between namespace scope, and class scope.

One that I can think of is that I would not be able to have a using
declaration or directive at class scope. I'm not convinced that is a great
loss. Can anybody think of other restrictions or differences that might
exist if a class were used as something of an instantiated namespace?

Is anybody aware of an example of this kind of design being used
(effectively)?
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

[Josh Mcfarlane]

Steven T. Hatton wrote:

It was once suggested to me that I could accomplish much the same thing that
modules would accomplish (if C++ had modules) by writing my entire program
- except for main() - inside of a class. When it was suggested, I didn't
take it very seriously, but I have recently begun wondering if it is an
idea worth considering. I'm now trying to think of what fundamental
differences might exist between namespace scope, and class scope.

One that I can think of is that I would not be able to have a using
declaration or directive at class scope. I'm not convinced that is a great
loss. Can anybody think of other restrictions or differences that might
exist if a class were used as something of an instantiated namespace?

Is anybody aware of an example of this kind of design being used
(effectively)?

Something that classes offer over namespaces is better encapsulation.
You control what other classes have access to, and what they don't.
Namespaces simply group things together and don't really offer that
kind of ability, so any other "module" can use your namespace without
any real protection from it. Classes on the other hand, through
encapsulation let you define what part of modules can interact.

Personal I have used classes to simply generic programming that the
programmer before me used. He had everything, including global
variables, lumped together. I took the functions, variables, and
grouped them together and then limited the scope to only what they
needed to (and fixed about 50-60 latent bugs in the process).

Sorta depends on what language you're coming from (for modules) but you
can think of classes as a very similar device. Class scope can be as
open (public) or as closed (private) as you want it to be, and that
flexibility will help you from creating alot of errors and hassle.

HTH,
Josh McFarlane

[Ian]

Steven T. Hatton wrote:

It was once suggested to me that I could accomplish much the same thing that
modules would accomplish (if C++ had modules) by writing my entire program
- except for main() - inside of a class. When it was suggested, I didn't
take it very seriously, but I have recently begun wondering if it is an
idea worth considering. I'm now trying to think of what fundamental
differences might exist between namespace scope, and class scope.
Visibility? You'd have to use struct or make everything public.

You'd have to put everything in one header.

Following on from that, you couldn't extend the namespace.
One that I can think of is that I would not be able to have a using
declaration or directive at class scope. I'm not convinced that is a great
loss. Can anybody think of other restrictions or differences that might
exist if a class were used as something of an instantiated namespace?

Is anybody aware of an example of this kind of design being used
(effectively)?

Not for a long time, the only times I came across this was back in the
days when namespaces were new and not supported by many compilers.

I suppose nested classes are a form of this.

Ian

[Steven T. Hatton]

Josh Mcfarlane wrote:

Something that classes offer over namespaces is better encapsulation.
You control what other classes have access to, and what they don't.
Namespaces simply group things together and don't really offer that
kind of ability, so any other "module" can use your namespace without
any real protection from it. Classes on the other hand, through
encapsulation let you define what part of modules can interact.

Personal I have used classes to simply generic programming that the
programmer before me used. He had everything, including global
variables, lumped together. I took the functions, variables, and
grouped them together and then limited the scope to only what they
needed to (and fixed about 50-60 latent bugs in the process).

Sorta depends on what language you're coming from (for modules) but you
can think of classes as a very similar device. Class scope can be as
open (public) or as closed (private) as you want it to be, and that
flexibility will help you from creating alot of errors and hassle.

HTH,
Josh McFarlane

Actually, in some ways what I'm contemplating is further from the concept of
a module than is a C++ namespace. If my class were strictly singleton, then
it would more readily qualify as a proper module. The closest thing to a
module I've used is probably Mathematica's package system.

I've got a pretty good idea of the basics of C++. I was really asking about
the more subtle issues. The best example is the one I've already
mentioned. That is, no using directives or using declarations at class
scope. I guess I could typedef my way around that if it proved useful.

What's going through my head is actually starting to scare me. It just
might prove useful.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

[Steven T. Hatton]

Ian wrote:

Steven T. Hatton wrote:

It was once suggested to me that I could accomplish much the same thing
that modules would accomplish (if C++ had modules) by writing my entire
program
- except for main() - inside of a class. When it was suggested, I didn't
take it very seriously, but I have recently begun wondering if it is an
idea worth considering. I'm now trying to think of what fundamental
differences might exist between namespace scope, and class scope.
Visibility? You'd have to use struct or make everything public.

You'd have to put everything in one header.

Well...two qualifications on that. 1) I could spread the blinkin' class
definition over a zillion files and the CPP would accept it. Not saying
this is a good thing, mind you. 2) I could still put the implementation in
a source file, even if that means lots of inner classes. But your point is
valid in the sense that doing otherwise with the definition would simply be
begging for trouble.
Following on from that, you couldn't extend the namespace.

This is correct. I will note that some people have suggested opening
classes in the same way namespaces are opened. I hope that doesn't survive
the Committee.

One that I can think of is that I would not be able to have a using
declaration or directive at class scope. I'm not convinced that is a
great loss. Can anybody think of other restrictions or differences that
might exist if a class were used as something of an instantiated
namespace?

Is anybody aware of an example of this kind of design being used
(effectively)?

Not for a long time, the only times I came across this was back in the
days when namespaces were new and not supported by many compilers.

I suppose nested classes are a form of this.

Very much what I was thinking. Basically the entire program would consist
of the one big outter class, and the rest would be inner classes, and other
class members. If I were to persue this course, and find it useful, it may
be worthwhile to create some mechanism for spreading the class definition
over multiple files, say in a directory which only held those files, and
with names reflecting the inner classes defined therein. It does, however,
sound rather kludgey.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

[Zorro]

A deep and informative discussion.

Class is a mechanism for CREATING new types so that their instances
will represent abstractions of the entities in the problem domain. On
the other hand, namespace is a packaging mechanism for libraries. One
of the problems that I had to fix with C++ is the implementation of
static methods. You can effectively turn a class into a namespace by
making everything static. That is how enumeration is (or was)
implemented in Java. Now, what does it mean for a type mechanism to
turn into a packaging mechanism?

I also extended namespaces so you can derive them from one another,
like classes. Then, I added private public and protected sections. The
public section is what a namespace exports. Finally, I separated the
definition of a namespace from its implementation, just as is done for
classes.

Yes, C++ lacks the notion of module (component, etc). Some special
cases are DLL. However, that was the very first thing I did in
extending C++ to component-oriented development.

Perhaps you will find these extensions easier to use than wasting time
on bending C++.

Regards,
Dr. Z.
Chief Scientist
zo****@ZHMicro.com
http://www.zhmicro.com
http://distributed-software.blogspot.com

[Steven T. Hatton]

Zorro wrote:

A deep and informative discussion.

Class is a mechanism for CREATING new types so that their instances
will represent abstractions of the entities in the problem domain. On
the other hand, namespace is a packaging mechanism for libraries. One
of the problems that I had to fix with C++ is the implementation of
static methods. You can effectively turn a class into a namespace by
making everything static. That is how enumeration is (or was)
implemented in Java. Now, what does it mean for a type mechanism to
turn into a packaging mechanism?

I also extended namespaces so you can derive them from one another,
like classes. Then, I added private public and protected sections. The
public section is what a namespace exports. Finally, I separated the
definition of a namespace from its implementation, just as is done for
classes.

Yes, C++ lacks the notion of module (component, etc). Some special
cases are DLL. However, that was the very first thing I did in
extending C++ to component-oriented development.

Perhaps you will find these extensions easier to use than wasting time
on bending C++.

Regards,
Dr. Z.
Chief Scientist
zo****@ZHMicro.com
http://www.zhmicro.com
http://distributed-software.blogspot.com

You MySQL is down.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

[Zorro]

The socket was gone. Sorry about that. It is up now, and thanks for the
help.

Thanks,
Z.

[Mercator]

Steven T. Hatton wrote:

It was once suggested to me that I could accomplish much the same thing that
modules would accomplish (if C++ had modules) by writing my entire program
- except for main() - inside of a class. When it was suggested, I didn't
take it very seriously, but I have recently begun wondering if it is an
idea worth considering. I'm now trying to think of what fundamental
differences might exist between namespace scope, and class scope.

This article series might interest you:
http://www.cuj.com/documents/s=8064/cuj9806saks/

[Kev]

"Josh Mcfarlane" <da*****@gmail.com> wrote in news:1121729159.955525.190150
@o13g2000cwo.googlegroups.com:

Personal I have used classes to simply generic programming that the
programmer before me used. He had everything, including global
variables, lumped together. I took the functions, variables, and
grouped them together and then limited the scope to only what they
needed to (and fixed about 50-60 latent bugs in the process).

Im pretty new to namespaces, certainly custom ones. At the moment the only
one I have includes a few classes for somewhat specialized random functions
that are used in many places. Ex: MyClass::Random::Truck(). The static fix
was unexpected but wasnt really a problem after figuring it out... which
admittedly wasnt a snap for me ;o)

But they do seem to help me organize things more. Before, I simply included
instances of the relevant classes when I needed them.... Random.Truck(). I
know "Random" wasnt a good choice.. and will be fixed. If they were only
needed in a few places, would using classes be the better choice?