IMHO, the upward compatibility is extremely important. Users (for SDL
these are game programmers) who are in the middle or at the end of
something in their apps will hate to hear the next version of the
library will have them to change things and/or learn new things or they
have to stuck forever with the old version (to fixing and patching of
which, apparently much less efforts will be dedicated, if any). And just
a thought of a necessity to use the ‘compatibility layer’ could make
some of them mad. I do not mean to say programmers do not want to learn
new things – this is just that whereas for SDL designers the library is
"a big thing", for the particular user it very well may be “one of many
those other things I have to think of while doing MY BIG THING” – and
this is a very natural attitude, especially if the library is really
cool i.e. it has not required major maintenance efforts from the user
so far.
So, my personal attitude is not to ask why I should keep the existing
interface, but instead to investigate any possibility to keep it and
only break the compatibility if I have got a REALLY SOUND REASON for it.
Even if I beleive I have such, I usually try to postpone the
compatibility breaking decision until as late as possible … and
sometimes my such laziness pays off handsomely!
Back to the original issue (I beleive it was about adding new things,
like windows, to the SDL) I do not see a good reason to break the
compatibility here. For example, to support window event one way is to
just add another function, like SDL_InstallEventQueueHandler(Some
callback, void context); then, a separate library like winsdl can be
added (to save the memory for those who do not need windows; they would
not need to call that new function either). Those who need windows would
call something like
SDL_InstallEventQueueHandler(SDLWIN_translateToWinEvents, / e.g.
SDLWIN_WindowManager * */ ctxt) once in the beginning of their app with
SDLWIN_ things defined in winsdl. After handler would has been
installed, functions like SDL_WaitEvent would return special new window
types of events instead or together with SDL_KeyboardEvent,
SDL_MouseButtonEvent et al. (e.g. SDLWIN_MouseButtonEvent) and all those
SDLWIN_… events would contain window id (e.g. within some
SDLWIN_WindowManager).
This is just an example of course, more work would be required and it is
surely possible to chose a different technique to access window events.
Pavel
||**||
Matthias Bach wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi!
Maybe I did phrase my comment the best way possible.
…
This is were some might have got me wrong. I just wanted to tell, that when
doing a new version you first shouldn’t think about making it compatible to
the old stuff, as that is gonna limit the possibilitys of the new versions
architecture. The better way would be to do a new version, and thand do
something like an SDL1forSDL2 compatibility-Layer. That might e.g. be in an
SDL1.3.0.so (or DLL) for compatibilty reasons. This would get maximum
features and performance out of the new version, and would still keep old
programms happy. It would also have the advantage of any new programm being
able to make use ONLY of the new lib, and not carying the old calls with it.
But as you said
…