Pike's SDL.Event:poll() works unintuitively when compared to SDL's SDL_PollEvent()
Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3960
Reported by Hermann Kruud, hermannkruud@yahoo.co.uk
One would expect that SDL.Event:poll() works like SDL_PollEvent(event), but SDL.Event:poll() doesn't remove the event from the queue into the Event object. Thus it works like SDL_PollEvent(NULL). The first one would be the expected behaviour, because SDL.Event:poll() is an instance method. Why else would it be Event class' instance method if it had nothing to do with the Event object?
Documentation for SDL_PollEvent [http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fPollEvent] says:
int SDL_PollEvent(SDL_Event *event);
Polls for currently pending events. If event is not NULL, the next event is removed from the queue and stored in the SDL_Event structure pointed to by event.
But Pike's SDL module's source [post_modules/SDL/SDL.cmod] shows that SDL.Event:get() works like one would expect SDL.Event:poll() to work:
PIKEFUN int get() {
RETURN SDL_PollEvent(&THIS->event);
}
PIKEFUN int poll() {
RETURN SDL_PollEvent(NULL);
}
There is no function in SDL that resembles SDL.Event:get() by its name e.g. SDL_GetEvent(). I think that for the sake of consistency SDL.Event:poll() should work like SDL_PollEvent() and SDL.Event:get() should be deprecated. A method SDL.Event.check() (not very consistent either) or SDL:poll_events() should be added to replace the functionality of the current SDL.Event:poll() functionality.
Then again there might not be a problem with the current SDL.Event:poll() functionality if Pike supported static (class) methods. This way it would be intuitively clear that the the static poll() method doesn't change the state of any object, but is still bound to the Event class.
Maybe this is all nitpicking and I should just write a patch to the Pike's SDL module documentation that explains how SDL.Event:poll() and SDL.Event:get() work. Discussion is open.