Jump to content
  • Advertisement
Sign in to follow this  
Jiia

Namespaces in classes

This topic is 4718 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement
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();
}
};

Share this post


Link to post
Share on other sites
If I remember properly, Objective-C lets you do things like that. C++ does not. Oh, well.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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)?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!