Drop the 'render' prefix? about sdl2 HOT 14 CLOSED

Unless you are deviating too much from the original SDL2 API, I would say: stick to standard SDL2 names. That way SDL1/2 documentation may be, with small changes, valid for Haskell.

from sdl2.

We are a far bit different from SDL in things like window creation, but probably not so much with the actual app drawing logic.

from sdl2.

IMO the order of priorities for naming goes:

1. Unambiguous
2. Consistent
3. Short

If some things really need the prefix to satisfy no. 1, then everything related should have one to satisfy no. 2.

from sdl2.

I have explored this work in the https://github.com/haskell-game/sdl2/tree/renderer-naming branch. I am happier with the naming there - and I believe it's more consistent than it was before. Would appreciate feedback, though if I don't get any I'm going to assume you're all Unix processes - no output means "OK" 😄

from sdl2.

I think that renaming the procedures from their original names in the C API is not the best idea. Whenever I used this library, I always checked https://wiki.libsdl.org/ for documentation and the 1-1 mapping between the names was invaluable. Now I'd have to remember the new names and how they correspond to the old ones -- or have to look this up all the time.

Sure, a more consistent API is nice, but for me, the drawbacks outweigh the positives.

from sdl2.

Counterargument @tempname11: with comprehensive documentation on Hackage, couldn't we make it so that's your starting point rather than the SDL wiki? Equivalent names (and even wiki links!) could be listed in the haddocks for Graphics.UI.SDL, so that even if you're translating a C++ example you're only a Ctrl-F away from whatever you need.

from sdl2.

@tempname11 but SDL is not trying to be a 1:1 mapping - for example window creation and audio buffer usage is radically different. If you want 1:1 mappings, then you would use SDL.Raw.

@tejon The latest documentation links directly to the underlying SDL function call's wiki page for almost everything. So yes, you are indeed just a Ctrl-F away :)

from sdl2.

@ocharles Just to emphasize, an important bit of that is having the original function's name plain-text in the Haskell docs, so if you're coming from a non-Haskell source (tutorial, etc.) the translation is trivial.

from sdl2.

I tend to agree with both @ocharles and @tejon. The API is (and is supposed to be) very different at times, so I wouldn't expect to have the very same names as in the C bindings. However, having the name of the SDL function(s) that we relate to in a certain API method at hand could be very helpful indeed. Not sure though if this will always be the case, particularly so once we reach a fully "self-contained" state.

from sdl2.

@tejon We link to the wikipage with the full URL, so the original name should be searchable.

It also occurs to me that the half the functions I'm renaming here (renderDrawColor -> rendererDrawColor) were already inconsistent with the SDL2 library, which has RenderSetDrawColor and RenderGetDrawColor)...

I'll keep thinking on this.

from sdl2.

I think I will undo the naming of blitSurface and blitScaled, as they are quite radically different. The only one I'm not sure about is fillRect and fillRects - I've basically swapped those symbols. That might be unjustifiably confusing.

from sdl2.

OverloadedRecordFields planned for GHC 7.12. Worth going over the data types again?

from sdl2.

I don't think just yet, older versions will be in package managers for a
good while.

On Sat, 29 Aug 2015 10:07 am tejon [email protected] wrote:

OverloadedRecordFields planned for GHC 7.12
http://thread.gmane.org/gmane.comp.lang.haskell.ghc.devel/9466. Worth
going over the data types again?

—
Reply to this email directly or view it on GitHub
#67 (comment).

from sdl2.

I think I'm going to stick with the original branch and get this merged.

from sdl2.