Horde3D

Hmm... in that case, why not make them both 300? Is there a reason they differ from each other?

I'm a fan of the self documenting nature of this approach.

Shortening of enum names can be done at the user/application-level if desired:

The enums have different values/numbers since they have different semantics (although the name is the same). Using different numbers for all enums gives some form of type safety to the whole system. For example, you will get an error when you try to give a ModelNodeParam to a Emitter since the ModelNodeParam enum has different values than the EmitterNodeParam enum.

If we use pure enums (not wrapped in structs), we would still require some prefix to make the code understandable without having to check the documentation all the time. D3D has such prefix as well, for example D3DBLEND_ZERO which is in the D3DBLEND enum. So in the end we would not win much over having the enum in a struct.

What we could do though is trying to find shorter names and more abbreviations, for example TexData instead of TextureResData. That would already help.

This is a quite subtle thing but I think the prefix h3d makes the code slightly harder to read. I think the reason is that all letters are "tall", so it is more difficult to quickly spot the following capital letter of the function name which is more important than the prefix of course. I would propose to use the prefix hg instead which stands for "horde graphics". I think that makes sense as well, is even shorter and the code looks just a bit nicer.

"hg" is easier to type than "h3d"

IMHO it's better to use "hgGetResParam" instead of "hgGetResourceParam" [shortening the "Resource" to the "Res"] and following changes will make the api easier to learn/remember :

I agree with "hg" and "Res" instead of "h3d" and "Resource" - but I really don't like your other proposal; there are no underscores in the API, and none should be introduced.

Edit: I just realized that there actually are underscores in the new enum names. That doesn't look good. And what meaning do "E", "PF", "PS", etc. have anyway? I think that naming scheme should be re-thought.

True. The only reason I brought this up instead of using that suits me better is that I really would like not to diverge from main distribution (and documentation).
Consistent rename in similar style would solve my problems. Thanks!

About prefixes, for what it's worth, I'm using Horde from Scheme, and at first I tried using "h3d" prefix too, but eventually switched to just "h:". You can simulate this in C++ with "h::" prefix; it's pretty but I guess too generic.

Speaking about "hg" -- "hg" is the command-line name of mercurial DVCS, so you might not want to have this clash. Anyhow, "hg", "h_" "h3d" -- I'm ok with any choice.

'h' strikes me as a little too generic, 'hg' doesn't really say 'horde' to me... 'h3d' is immediately recognisable as 'horde3d', so seems preferable.

_________________
Tristam MacDonald - [swiftcoding]

In general I am against underscores as well. But here we have a special case where the prefix indicates the data type. E_ means element, PI_/PF_/PS_ int/float/string parameter and S_ stream. I think that is an acceptable convention here but I am open for better suggestions.


Seems we have differern ways of thinking: When the pattern recognition matches, the name conversion is for free in my pipeline
But honestly, what about the prefix hor like in horSetNodeParamF()? It would be something in-between.

A literal pronunciation of 'hor' is identical to 'whore'.

To me, the cleanest approach (both by clarity and readability) would be 'h3d_', as in h3d_SetNodeParamF. This clearly delineates the namespace from the function name, allows the first letter of the function name to be immediately identified, and is very strongly related to 'horde3d'.

I don't think the overhead of typing additional 2 characters is a problem - all programmers are fast typists, right

_________________
Tristam MacDonald - [swiftcoding]

"hg" without "_" is easier to type because "h" & "g" keys are near together. There is no need to search for the "3" & "d" keys and hold "Shift"+"-" most of the times

How about "hrd" (Horde3D)?

That is kind of what I meant, I don't think laziness is a good foundation for API design - learn to touch type, and you wont care either way

_________________
Tristam MacDonald - [swiftcoding]

Roger that ^_^

imho h3d* is the best one. it's simple and descriptive in the same time

_________________
Paul