I must find function name when I write sdl2 code for nim.
For example:
var window = createWindow("Hellow World!", 100, 100, 565, 67, SDL_WINDOW_RESIZABLE)
var render = createRenderer(window, -1, RENDERER_ACCELERATED or RENDERER_PRESENTVSYNC or RENDERER_TARGETTEXTURE)
#OK, SDL_WINDOW_RESIZABLE macro the same with sdl2 lib, but why RENDERER_ACCELERATED hasn't SDL_?? Maybe all macros must remove SDL_?
var window_screen = window_screen = getSurface(window)
# SDL_GetWindowSurface function name is change to getSurface, Why not getWindowSurface? I don't know how many functions and macros have been modified.
I often need to write c++ and Nim code, but if a lot of function name are not the same, this is very bad. I think perhaps Vladar4/sdl2-nim is better than official sdl2 nim, It's not chaos.I'll agree that having some enums with SDL in front and others without is weird... from looking through the source, it looks like the vast majority of constants keep the SDL in front so I think it's just an oversight with the renderer consts.
However, with functions like SDL_GetWindowSurface(), since the first parameter is a handle to the window, it's more idiomatic to write window.getSurface(), rather than getWindowSurface(window), so I think the name change in those cases make sense, and seems to be done in a consistent way. At least for me, this seems easier to read and work with.
Here's some of my thoughts on naming.
Every C library needs its prefixes like SDL_* cause there's no namespaces in C. But in Nim you can do sdl.* instead. And it's beautiful.
rku: Changing names of wrapped functions bites in the ass because then we can not rely on official docs.
I hardly consider it as a renaming, and you can use official docs all right, honestly.
rku: In this case does nim-sdl docs exist?
Some remarks:
Having the long C name is nice when porting from C or when consulting C docs. Short names are nice for typing, reading sources or when porting from languages like Ruby or Python. So generally we can offer both. I do not know much about SDL, but I guess it is similar to GTK, where I use for example
proc set_sensitive*(widget: Widget; sensitive: gboolean) {.
importc: "gtk_widget_set_sensitive", libgtk.}
proc `sensitive=`*(widget: Widget; sensitive: gboolean) {.
importc: "gtk_widget_set_sensitive", libgtk.}
{.deprecated: [gtk_widget_set_sensitive: set_sensitive].}
So
var w: Widget
w.sensitive = true
w.set_sensitive(true)
gtk3.set_sensitive(w, true)
gtk_widget_set_sensitive(w, true)
works all. The deprecated statement works not good for overloaded functions unfortunately, and Araq said it maybe never will. (see https://github.com/nim-lang/Nim/issues/1762) So we may use
const gtk_widget_set_sensitive* = set_sensitive
I know that some people do not like the module name prefix, for example Araq prefers wx_name instead of wx.name. For that Nims source code substitution may work, so that for module wx the string " wx_" is automatically replaced to " wx.". Not tested yet, maybe something like "# replace(sub = " wx_", by = " wx.")" at the start of Nim code may work?
One advantage for Nim is, that we have the original C functions names available in the wrapper file, so a grep gives us all what we need if we are unsure. For Ruby GTK/Gnome I have spent hours just to find the correct Ruby name of some functions, constants or enums...