when CaseSensitivity == "full" or CaseSensitivity == "partial":
const GL_CULL_FACE* = 0x0B44
else:
const cGL_CULL_FACE* = 0x0B44On a related note, it would be good if one could specify in the *.nimble file which case sensitivity modes are supported by the library. One would need a flag for each in the *.nimble file, as one can easily be compilable in "full" mode and fail in "partial" mode, especially due to transitive dependencies on other libraries and how one uses them. This would also be useful for filtering a nimble search based on which case sensitivity types one supports.
(As a frustrated side note, I personally have no problem adapting to various different standards in different code bases using CamelCase or snake_case or CPP_CONSTANT case or whatever. But having an equivalence class between all of these has given me nasty surprises or seriously confused me on occasion.)
(Side note 2: The linked syntax cheatsheet seems to be missing a lot of stuff all of a sudden, including how to typeset code.)
You can only use when declared(NimVersion) which defaults to cs:partial. Also you are not supposed to set --cs anywhere. This switch will be removed from the language, there is no choice.
On a related note, it would be good if one could specify in the *.nimble file which case sensitivity modes are supported by the library
You are really not supposed to support different modes, the stdlib does not either.
Side note 2: The linked syntax cheatsheet seems to be missing a lot of stuff all of a sudden, including how to typeset code.
Thanks. Fixed.
Ok, got it. So is there a recommended way to deal with conflicts like GLdouble and GL_DOUBLE (and a number of others) which are still affected by "partial"? It would be good to get a clean solution that is used uniformly amongst all cases where we have to deal with such things.
One way that I could think of is to put all constants and types in different sub-namespaces, but not a fan due to the increased verbosity in the seemingly random conflicts that pop up, making the namespace look like random litter in the code.
So is there a recommended way to deal with conflicts like GLdouble and GL_DOUBLE (and a number of others) which are still affected by "partial"?
I don't know of any way that can be applied universally. For OpenGL you could use GL_DOUBLE_RANGE and GLdouble. Well, IMHO GLdouble and GLfloat etc shouldn't exist in the first place, use float64 or float32. Is there any platform where GLdouble is not C's double?
I don't know of any way that can be applied universally. For OpenGL you could use GL_DOUBLE_RANGE and GLdouble. Well, IMHO GLdouble and GLfloat etc shouldn't exist in the first place, use float64 or float32. Is there any platform where GLdouble is not C's double?
Agreed for the floating point values. But it's not as obvious for GLshort GL_SHORT and possibly GLint GL_UINT. Either way, is it worth establishing a rule for how to deal with such cases in general, or do you expect such conflicts to be rare and handled in their own library-author-specific-way? How should/would c2nim it if at all?
(By the way, the Syntax Cheatsheet link still shows me a limited view: http://nimrod-lang.org/rst.html)
But it's not as obvious for GLshort GL_SHORT and
Yes, such name conflicts can generate much headache -- fortunately there are not too much conflicts for GTK3 related stuff. 6 months ago I had the idea to allow a trailing underscore for identifiers, which indicates that this identifier has to be written exactly in this way always. So we could use GLshort GL. Not very nice, but would work. (Proposed in the forum.)
May it be a solution to have lists of identifiers which has to be written in exactly that way? If you had in the GL module a list at the beginning containing GLshort and GL_SHORT it would indicate that the two identifiers exists exactly as written here. Whenever module GL is imported, the compiler may compare all identifiers with this lists and disable all mangling for these? No idea if there is a chance that this may work.
A related issue: May it be possible to advice the compiler to give name suggestions? Similar to existing deprecated pragma? Assume you decided to use name float64 for GL_double in your wrapper. If someone uses your module and uses identifier GL_double compiler would conplain that this type does not exist. Would be more helpful if compiler could suggest use of float64 instead?
Either way, is it worth establishing a rule for how to deal with such cases in general, or do you expect such conflicts to be rare and handled in their own library-author-specific-way?
I know they are rare. ;-)
By the way, the Syntax Cheatsheet link still shows me a limited view
Browser cache.
May it be possible to advice the compiler to give name suggestions?
nimfix can do that.
6 months ago I had the idea to allow a trailing underscore for identifiers, which indicates that this identifier has to be written exactly in this way always.
6 months later I still don't like that idea too much. How about having a small section in the library documentation like "These 3 rarely used identifiers had to been renamed to these due to name conflicts. Maybe you can enjoy this 50K LOC wrapper nevertheless."
If someone uses your module and uses identifier GL_double compiler would conplain that this type does not exist. Would be more helpful if compiler could suggest use of float64 instead?
We have that already with the deprecated statement.