Back to General and Gameplay Programming

Namespaces in classes

General and Gameplay Programming Programming

Started by Jiia July 20, 2005 12:52 AM

35 comments, last by Holy Fuzz 18 years, 9 months ago

Jiia

593

Author

July 20, 2005 12:52 AM

This doesn't seem to be possible. But wouldn't it help a lot? I wish I could derive a world-like object from an engine-like class to recieve some functionality from it, but it would be nice to keep it's engine-level routines seperate from the object's worldly routines. Here's an example:


class ParticlePhysics
{
public:
   namespace Particle
   {
      void UpdatePhysics();
      void UpdateFade();
      void DieOut();
      void StartFloating();
   };
private:
.....
};

class MadMan : public ParticlePhysics
{
public:
   void Update()
   {
      Particle::UpdatePhysics();
   }
private:
...
};

Compare to something like this:

class ParticlePhysics
{
public:
   void Particle_UpdatePhysics();
   void Particle_UpdateFade();
   void Particle_DieOut();
   void Particle_StartFloating();

private:
.....
};

class MadMan : public ParticlePhysics
{
public:
   void Update()
   {
      Particle_UpdatePhysics();
   }
private:
...
};

This is a really bad example. I have no idea why MadMan would want to be derived from a particle. But I find myself having this problem sometimes. Some classes are made to be derived from for this purpose. And I wish there was some way to prevent confusion. Is there another way? Thanks for any suggestions

JohnBolton

1,373

July 20, 2005 01:03 AM

It's a bad idea. Basic rule of thumb: a class should do only one thing.

Besides, in your example, the namespace doesn't do anything except add redundant scope. Just do this instead:

    class MadMan : public ParticlePhysics    {    public:        void Update()        {            ParticlePhysics::UpdatePhysics();        }    };

John BoltonLocomotive Games (THQ)Current Project: Destroy All Humans (Wii). IN STORES NOW!

Fruny

1,658

July 20, 2005 01:22 AM

If I remember properly, Objective-C lets you do things like that. C++ does not. Oh, well.

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan

Jiia

593

Author

July 20, 2005 04:24 AM

Quote:Original post by JohnBolton
It's a bad idea. Basic rule of thumb: a class should do only one thing.

It's not an idea, I just want to make things easier to organize and follow. I'm not sure I understand the relevance of your basic rule of thumb statement.

Quote:Besides, in your example, the namespace doesn't do anything except add redundant scope.

Isn't that what all namespaces do? That's what I wanted it to do. Same reasons.

Quote:Just do this instead

That's pretty obvious, but it's more than just about calling the function name.

Thanks for your time

MaulingMonkey

1,729

July 20, 2005 04:55 AM

Quote:Original post by Jiia
Quote:Original post by JohnBolton
It's a bad idea. Basic rule of thumb: a class should do only one thing.

It's not an idea, I just want to make things easier to organize and follow. I'm not sure I understand the relevance of your basic rule of thumb statement.

He's critisizing the fact that your design makes you feel the need for such prefixes.

Quote:
Quote:Besides, in your example, the namespace doesn't do anything except add redundant scope.

Isn't that what all namespaces do?

No, namespaces add scope/organization so things dont clash. This repeatedly, reiteratingly (that a word?) and redundantly adds scope/organization:

You can use the ClassName:: prefix to access that scope to prevent clashes
just like:
You can use the NamespaceName:: prefix to access that scope to prevent clashes
outside of a class.

There's no need to wrap all the members of ParticlePhysics in a namespace scope, because they're allready in a class scope.

Quote:This is a really bad example... But I find myself having this problem sometimes.

Why create a bad example when you allready have examples (your previous experiences)?

Jiia

593

Author

July 20, 2005 01:32 PM

Quote:Original post by MaulingMonkey
He's critisizing the fact that your design makes you feel the need for such prefixes.

Criticizing was not the help I was looking for, but I still don't see the relevance, or why we're thinking that bad design is lurking.

Quote:There's no need to wrap all the members of ParticlePhysics in a namespace scope, because they're allready in a class scope.

...

Why create a bad example when you allready have examples (your previous experiences)?

The method is exactly the same; I'm deriving from a class. The inherited class is very complex, and the base class is very simple. I use the IDE's tools to access and write code, and that means a lot of functions exist for this class that are all thrown together. Compiler auto-completion alone is enough reason to use prefixes. There are about five functions that deal with collision. It would be nice to provide a Collision:: prefix for them in the class. There are at least 15 that work with animations, 6 that update commands, 8 that update command tasks, 13 that handle equipment and armor, five or so that just divide normal updating code, around 12 for AI routines, and 3 for input.

When I type Character->, I get a table of contents. It's great, I would just like to organize it.

JohnBolton

1,373

July 20, 2005 02:05 PM

Quote:Original post by Jiia
I'm not sure I understand the relevance of your basic rule of thumb statement.

I assume by wanting namespaces inside a class, you want to do something like this:

    class A    {        namespace X        {            ...        }        namespace Y        {            ...        }        namespace Z        {            ...        }    };

This implies to me that the class has three separate behaviors or modes of functionality. Better would be to divide A into three separate classes, or make X, Y, and Z classes rather than namespaces.

John BoltonLocomotive Games (THQ)Current Project: Destroy All Humans (Wii). IN STORES NOW!

Jiia

593

Author

July 20, 2005 02:38 PM

Quote:Original post by JohnBolton
This implies to me that the class has three separate behaviors or modes of functionality. Better would be to divide A into three separate classes, or make X, Y, and Z classes rather than namespaces.

All three behaviors are exclusive to A. Wouldn't adding a new class for every routine that requires more than one function make a mess of things? The routines deal directly with the object. They are part of the object. I would have to pass this pointers to each class function just to have it function properly. Then there's the matter of private data, which the routines obviously need. I would end up making my whole project a huge library of one-use classes. That doesn't sound like the answer I'm looking for.

illone

151

July 20, 2005 03:42 PM

without a specific example of when this usage pattern would be
required/prefered, it may be hard for others to see why one would
want to use it. if you have a pre-existing example, sharing it
might help others see what you mean.

in your example, it seems like your Particle Physics class is managing
particle physics and particle persistence as well some display
functionality (though i may be misinterpreting what fade out is doing).
that would be 2 maybe 3 seperate seperate processes stuffed into one
class. and then the class being derived by 'Madman' helps little in
explaining how this usage pattern could be helpful.

illone

illone

Jiia

593

Author

July 20, 2005 05:29 PM

I have a large, complex class that is very flexible and does many different things. I want to organize all of the routines it can perform.

I'll find my own way. I appreciate the help.

Namespaces in classes

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Namespaces in classes

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines