Horde3D

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?

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"

Hehe, now that you say it I recall some song texts...in that case h3d is the preferred alternative
Thanks DarkAngel for saving us from that!

Sounds like a good idea - will make the C interface much more user friendly.

_________________
Tristam MacDonald - [swiftcoding]

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"

IMHO replacing the enums with namespaces would cause some performance penalties. If I get you right, this piece of code :
Should be changed to this :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.

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).

Thanks

IMHO using namespaces is more comfortable [auto code completion]

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.

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?

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.

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


just use

Or am I missing the point?

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.

Yeah, that part should not be copied; for constants enums look better than defines.

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.