Re: Special treatment for TValue in structs
- From: Joshua Day <josh.day@xxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Sun, 2 Sep 2012 23:26:15 -0400
Dimiter 'malkia' Stanev wrote:
> But now you are mixing internals with externals.
>
> My understanding is that luajit vm makes everything possible not to expose
> it's internals to any code that it's running. This allows the VM to make
> certain assumptions, and not verify, fix itself on every possible corner
> (if that is ever possible).
My goal is quite the opposite: To have dynamic members in structs, which
would necessarily be well behaved (so long as you were careful to keep
their references alive and didn't try to break them by bit fiddling). TValue
seemed to me like a good name, on account of it being the name used
internally, but you could as easily expose the type as lua_value or dynamic.
The point is that it would be nice to have a reference from an ffi struct to
a Lua value -- be it string, table, number, function, or anything else --
which you can treat the way you would treat any other Lua value, because it
*is* a Lua value.
Right now any table can contain a reference to a struct (trivially), but no
struct can contain a reference to a table. It seems like an attractive
feature to me, to allow references the other way.
(The Lua API + ffi can already do what I think you thought I wanted, even
without an extra instance -- just make a C function that returns a small
userdatum for every TValue on the stack, and cdef TValue into existence
yourself. And no, I can't see why anyone would want that, either.)
As for my second question (the parenthetical, unimportant one): I'd like
to load a library with ffi.load and then call any exported lua_CFunction
with the Lua api, that is, have it called with the current lua_State and
proper stack management and everything. Again, not looking to poke around
in the current running vm; just interested in having more options for gluing
various uncooperative modules together, in unusual situations. If I'd asked
the two questions separately, they might have been less ambiguous. I should
have. (All they have in common is that they both seem fairly easy.)
--
Joshua
Other related posts:
