-
Hello, // TimerHandle
#[derive(Clone)]
struct TimerHandle<'a> (rs_timer::TimerHandle<LuaValue<'a>>);
impl LuaUserData for TimerHandle<'_> {}
impl<'a> TimerHandle<'a> {
fn new(lua: &'static Lua, ls: rs_timer::TimerHandle<LuaValue<'static>>) -> LuaResult<LuaTable<'a>> {
let res = lua.create_table()?;
res.set("_self",
lua.create_userdata(
TimerHandle(ls)
)?)?;
res.set("add_timeout", lua.create_function(TimerHandle::add_timeout)?)?;
Ok(res)
}
pub fn add_timeout(_: &Lua, (luaself, delay_from_now, data): (LuaTable, u64, LuaValue<'static>)) -> LuaResult<()> {
let ud: LuaAnyUserData = luaself.get("_self")?;
let ref_self = ud.borrow::<TimerHandle<'static>>()?;
ref_self.0.add_timeout(std::time::Duration::from_millis(delay_from_now), data);
Ok(())
}
} I may be very wrong but think that it's because Q: is it very difficult to have an alternative |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
I would suggest to try to store Also you could try to store Also I'm working on alternative implementation that will not require lifetimes for values but it's mostly a concept now. |
Beta Was this translation helpful? Give feedback.
I would suggest to try to store
LuaValue<'a>
as an associated value to a UserData (seeset_user_value
andget_user_value
)Also you could try to store
LuaValue
in Lua Registry and refer to it viaRegistryKey
.It would significantly simplity the "lifetimes hell".
Also I'm working on alternative implementation that will not require lifetimes for values but it's mostly a concept now.