LÖVE

Posted: **Tue Jan 12, 2016 3:07 pm**

So much better to wrap around a callback event system than some OO listener system.

Posted: **Tue Jan 12, 2016 4:46 pm**

Posted: **Tue Jan 12, 2016 5:49 pm**

airstruck wrote:

Take a look at the example here.

I would much rather have the love.keypressed,love.mousepressed, etc callbacks.

Posted: **Tue Jan 12, 2016 6:05 pm**

It's a lot simpler than having a robust, fully-featured event system isn't it?

But what will you do when you want to write some library code than needs to respond to events? Have your API require a bunch of boilerplate where the user writes stuff like this?

Code: Select all

function love.mousepressed (...)
    mylibrary.handlemouse (...)
end

function love.keypressed (...)
    mylibrary.handlekeyboard (...)
end

Or hook it yourself, cross your fingers and hope the user doesn't stomp on it by redefining that handler? But the user still needs to define handlers, don't they... so now won't you need to implement your own ad-hoc event system that they'll have to use instead?

Personally, I'd happily trade the simplicity of this event system for something a bit more flexible.

Posted: **Tue Jan 12, 2016 6:34 pm**

chimmihc wrote:Take a look at the example here.
I would much rather have the love.keypressed,love.mousepressed, etc callbacks.

Oh ok, i get it now, you're saying that you like how löve does it, with a game loop ([wiki]love.run[/wiki]) polling SDL events and calling callbacks ([wiki]love.event[/wiki]) inside that.

Yeah it's pretty neat... except, behind the scenes, löve uses tons of Objects and OO in general as well... I mean, the reason you can pass tons of different stuff into love.graphics.draw (Like canvases or images (both being specializations of the texture type) or spritebatches) is because their supertype is Drawable, which the function accepts as its argument.

As for what you linked, if you ever write your own lib code, or even just gamestates (with HUMP's gamestates for example, you will find that it has a registerEvents function that hooks the currently active state's callbacks to be run instead of löve's own, then as a last step, calls those as well. (Note that this isn't mandatory though)), you may need to have some functionality like that.

Posted: **Tue Jan 12, 2016 7:01 pm**

I am well aware of what happens behind the scenes. I am just saying for "scripting end" coding I prefer simple systems that are easy to wrap around and make custom systems rather than systems like Gideros and Corona SDK have.

Posted: **Tue Jan 12, 2016 7:33 pm**

airstruck wrote:But what will you do when you want to write some library code than needs to respond to events? Have your API require a bunch of boilerplate where the user writes stuff like this?

I think of that as a feature, because it allows me to know what is happening and when. No magic behavior or libraries doing stuff behind my back. I'm in control. This has two advantages: For one, it is easier to optimize code. But more importantly, it makes it easier to reason about the code and find bugs in it. Of course, this comes at the costs you mentioned, but in game programming (and other real-time stuff) the benefits outweigh the costs. In other areas (web programming, UI heavy stuff) the situation is different.

airstruck wrote:Or hook it yourself, cross your fingers and hope the user doesn't stomp on it by redefining that handler? But the user still needs to define handlers, don't they... so now won't you need to implement your own ad-hoc event system that they'll have to use instead?

hump does it that way, but only upon request. When this is done in love.load(), the library can reasonably assume that all callbacks are defined. If the callback is overwritten later on, it's either very intentional (for example, to temporarily suspend library callbacks) or very unintentional. The latter is unfortunate, but not the libraries fault: the user requested to overwrite the callbacks in the first place.

Posted: **Tue Jan 12, 2016 10:51 pm**

vrld wrote:
airstruck wrote:But what will you do when you want to write some library code than needs to respond to events? Have your API require a bunch of boilerplate where the user writes stuff like this?
I think of that as a feature, because it allows me to know what is happening and when.

In fact, love.event.addListener was a function in 0.10.0 for a short time before release, but ended up being removed for reasons like that (and some other reasons).

For example, if you were to make a game that has gamestates (most games do), and a library is used in a specific gamestate, you would want to make sure the library isn't grabbing and processing events while it isn't supposed to be active. It's very easy to get that wrong or have to do a lot of poking in library code if love.event.addListener were used by the library. It's much easier to do the right thing when it isn't used.

Posted: **Tue Jan 12, 2016 11:22 pm**

Maybe I'm not following this thread correctly, is this about the love event callbacks (love.update et al) or continuation passing style? I thought the love event callbacks being where library users make sure to call the library event handlers was pretty much the standard.

Posted: **Wed Jan 13, 2016 5:58 pm**

Inny wrote: I thought the love event callbacks being where library users make sure to call the library event handlers was pretty much the standard.

I think it is. Doesn't mean it's a great standard. Consider this code:

Code: Select all

function love.draw (...)
    somelibrary.handledraw(...)
end
function love.resize (...)
    somelibrary.handleresize(...)
end
function love.mousepressed (...)
    somelibrary.handlemousepressed(...)
end
function love.mousereleased (...)
    somelibrary.handlemousereleased(...)
end
function love.mousemoved (...)
    somelibrary.handlemousemoved(...)
end
function love.keypressed (...)
    somelibrary.handlekeypressed(...)
end
function love.keyreleased (...)
    somelibrary.handlekeyreleased(...)
end
function love.textinput (...)
    somelibrary.handletextinput(...)
end
-- and so on

In my view that's annoying and borderline unacceptable. The point of library code is to encapsulate functionality. When you have to wire up a shit ton of events by hand like this, that's the opposite of encapsulating functionality. I'd much rather do something like this:

Code: Select all

gamestate.push(function()
    somelibrary.handleevents()
end)

gamestate.pop(function()
    somelibrary.stophandlingevents()
end)

Of course that's entirely possible if you hook the callbacks in your library code. What's not possible is doing the hooking in a non-destructive way. It would have been possible with addListener, of course.

LÖVE

I LÖVE callbacks

I LÖVE callbacks

Re: I LÖVE callbacks

Re: I LÖVE callbacks

Re: I LÖVE callbacks

Re: I LÖVE callbacks

Re: I LÖVE callbacks

Re: I LÖVE callbacks

Re: I LÖVE callbacks

Re: I LÖVE callbacks

Re: I LÖVE callbacks