Passing tables as events arguments

[mariofutire]

Hi,

I've tried to use the event mechanism in love (0.9) and found that tables cannot be passed as arguments

Error: ball.lua:43: Argument 2 can't be stored safely
Expected boolean, number, string or userdata.

The reason seems to be that Variant::fromLua() wants to store a C++ only version of the lua value.
I know it is impossible to store tables in C++, but one could store the table somehwere in lua and only store its key in C++.

Let's say there is a table called

love.variants = {}

then each table -> Variant could do something similar to

key = #love.variants
love.variants[key] = table_to_store

and in C++ the Variant simply contains the key (used in toLua and in destructor)

Would it make any sense?

[slime]

I'd recommend using a pure Lua event system if you want to have custom events.

[mariofutire]

Could you please elaborate, I am very new.

I guess I could write my own event system that would be handled first thing on "update". But I would rather use core love2d if possible.
But what is the reason of a non pure Lua event system in love2d?

Andrea

[bartbes]

It's used as event sink for all OS events, and can indeed support custom events, but it might be tricky to work with. The reason Variant doesn't store references is because Variant is used to transport data between threads, for instance in Channels, but also in the love.event event sink (because love.event is mostly thread-safe).

[mariofutire]

I see, it would be impossible to move such objects across luaStates.

I've see a few event libraries, but I do not know how they work with love2d.

like Luevent, beholder.

how much integration do I need with love2d?
I imagine the possible solutions after an event is generated are

1) execute the handlers inside event.push() before it returns
2) queue them to be executed first thing in the next update()
3) have love2d handle them among all other things

3 clearly requires integration with love2d.
Does it matter?

[bartbes]

3) have love2d handle them among all other things

3 clearly requires integration with love2d.

Have a look at [wiki]love.run[/wiki] and you'll see that love.event's not as tied to love as it seems to be, you could very easily modify it and add your event handling after love's, and it will be practically indistinguishable.

EDIT: By the way, another reason why having love.event use Variants is a "good" idea is because this means that any point that introduces an event doesn't need a reference to a lua state to do so, and considering events typically aren't generated from lua, that is a nice property to have.

[mariofutire]

EDIT: By the way, another reason why having love.event use Variants is a "good" idea is because this means that any point that introduces an event doesn't need a reference to a lua state to do so, and considering events typically aren't generated from lua, that is a nice property to have.

I guess I keep thinking about love2d as pure lua, but as you say there must be a non lua part of it, where we might not have a luaState available.

Thanks for the suggestions I will definitely have a look around.

Andrea