Horde3D
http://horde3d.org/forums/

Namespaces
http://horde3d.org/forums/viewtopic.php?f=8&t=766		 Page 1 of 3
Author:  marciano [ 03.06.2009, 00:25 ]
Post subject:  Namespaces
I wonder if we should use old-school namespaces for functions and enums in the external interface. This would make the syntax and usage more consistent across different programming languages. Furthermore, it would solve the drawback that enums like ResourceTypes that have a quite common name are currently not in any namespace.

I would propose the prefix ho for all function names (e.g. hoAddResource) and Ho for enums (HoSceneNodeParams). Are there any better ideas?
Author:  DarkAngel [ 03.06.2009, 01:02 ]
Post subject:  Re: Namespaces
marciano wrote:
This would make the syntax and usage more consistent across different programming languages.
Yeah that makes sense. I would prefer the prefix of h3d though.

In English, 'ho' is an old word meaning something like "look over here" (e.g. land ho!), but in modern American slang it means "prostitute" :wink:
Author:  marciano [ 03.06.2009, 08:10 ]
Post subject:  Re: Namespaces
Hehe, now that you say it I recall some song texts...in that case h3d is the preferred alternative :lol:
Thanks DarkAngel for saving us from that!
Author:  swiftcoder [ 03.06.2009, 16:42 ]
Post subject:  Re: Namespaces
Sounds like a good idea - will make the C interface much more user friendly.
Author:  Siavash [ 04.06.2009, 12:13 ]
Post subject:  Re: Namespaces
Can you add a code sample here? Just wanted to know the changes should be performed on the code. [Perhaps this will be problematic]
Author:  DarkAngel [ 05.06.2009, 00:36 ]
Post subject:  Re: Namespaces
Siavash wrote:
Can you add a code sample here? Just wanted to know the changes should be performed on the code. [Perhaps this will be problematic]
I'm guessing the changes on Horde users would be fairly straight foward, even as simple as:

Find: "Horde3D::"
Replace with: "h3d"
Author:  Siavash [ 05.06.2009, 05:05 ]
Post subject:  Re: Namespaces
IMHO replacing the enums with namespaces would cause some performance penalties. If I get you right, this piece of code :
Code:
Horde3D::findNodes(StartNode, NodeName, 3);

Should be changed to this :
Code:
H3DfindNodes(StartNode, NodeName, SceneNodeType::Mesh);
And we can't use the first code anymore.

Assume that we are sending the SceneNodeType from Lua to the C. Now we must add an extra if/switch to the C code to decide which SceneNodeType must we use.

IMHO the current structure of engine is more straight forward. We just need to send the SceneNodeType as int to C and there is no need to any if/switch statements.
Author:  Expandable [ 05.06.2009, 06:05 ]
Post subject:  Re: Namespaces
Siavash wrote:
IMHO replacing the enums with namespaces would cause some performance penalties.


If I understood the suggestion correctly, the point is to remove all C++ namespaces and make the interface entirely pure C compatible. So the Horde3D namespace is removed, and all functions and enums are prefixed with "H3D" or "h3D" (I'd prefer the latter).
Author:  Siavash [ 05.06.2009, 10:20 ]
Post subject:  Re: Namespaces
Thanks 8)
Author:  Siavash [ 06.06.2009, 06:28 ]
Post subject:  Re: Namespaces
IMHO using namespaces is more comfortable [auto code completion] :wink:
Author:  Expandable [ 06.06.2009, 11:30 ]
Post subject:  Re: Namespaces
Siavash wrote:
IMHO using namespaces is more comfortable [auto code completion] :wink:


Hmm, I don't know about other IDEs, but Visual Studio makes no difference between auto-completing namespaces and identifiers. The only difference is, though, that you can import the namespace using the "using"-keyword and get rid of it all together. On the other hand, I really like the OpenGL's "gl" prefix. In my opinion, the "h3d"-prefix is the way to go.
Author:  magv [ 07.06.2009, 00:56 ]
Post subject:  Re: Namespaces
Regarding naming of things, is there anything that can be done to make enum names shorter?
I don't know how do other people feel, but for me things like "emitter-node-params::particle-effect-res" or "particle-effect-res-params::move-vel-endrate" are a pain to see in the code (consider 80-column limit).

Here's a proposal. Along with moving everything under h3d prefix, also move constants into a single namespace, eliminating prefixes like "EmitterNodeParams::".

I'm thinking about how OpenGL does that: all constants are simply GL_SOMETHING. In the same spirit AnimationResParams::FrameCount becomes h3dAnimationFrameCount, H3D_ANIMATION_FRAME_COUNT, or anything similar.

This could also benefit bindings to the languages without namespaces (C?).

So, does anyone think it's worth the effort?
Author:  marciano [ 07.06.2009, 10:04 ]
Post subject:  Re: Namespaces
magv wrote:
Regarding naming of things, is there anything that can be done to make enum names shorter?

Yes, that's something I found not so nice myself as well. It is especially obvious for the resource data interface which takes two enums that are rather long. The advantage of having the enums wrapped in a struct is that you can easily see what enum values are available for a given parameter. If you just have the enums as in GL, you need to look at the documentation to see which enums are allowed. Hmm, maybe someone has another idea how to make that nicer.
Author:  Expandable [ 07.06.2009, 10:55 ]
Post subject:  Re: Namespaces
Enums in OpenGL are just #defines, aren't they?

Anyway, why not just use enums the standard C++-way? That would make the notation shorter and you'd still know which enums you're allowed to use. So instead of

Code:
// Enum definition
struct EngineOptions
{
     enum List { Opt1, Opt2 };
};
// Function definition
void func(EngineOptions::List e);
// Function call
func(EngineOptions::Opt1);

just use
Code:
// Enum definition
enum EngineOptions { Opt1, Opt2}
// Function definition - shorter and less ugly, and even preserves type information
void func(EngineOptions e);
// Function call - shorter
func(Opt1);

Or am I missing the point?
Author:  magv [ 07.06.2009, 12:57 ]
Post subject:  Re: Namespaces
marciano wrote:
The advantage of having the enums wrapped in a struct is that you can easily see what enum values are available for a given parameter.
Yes, that is one of the annoyances of the OpenGL approach. Autocompletion for such constants is not very useful, and once you have similar names like GL_TEXTURE and GL_TEXTURE_2D, you really need documentation opened at all times (which I do anyway for various reasons -- but that's just me).

Anyway, I don't insist on the proposed way. If there's any other way to shorten the names, then I'm all for it.

Expandable wrote:
Enums in OpenGL are just #defines, aren't they?
Yeah, that part should not be copied; for constants enums look better than defines.

Expandable wrote:
Anyway, why not just use enums the standard C++-way?
That actually was my first impulse also, but unfortunately there are conflicts: MeshNodeParams::MaterialRes is 300, while LightNodeParams::MaterialRes is 500, so you can't just use MaterialRes everywhere, you have to use the prefix.
Page 1 of 3 All times are UTC + 1 hour
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/