Re: Luajit cdata with metatables....

[Francesco Abbate <francesco.bbt@...>]

2011/4/5 Mike Pall <mikelu-1104@mike.de>:
> My plan is to add metamethods for cdata objects. This is a much
> better solution, but I don't know when I get around to implement
> it. It would look something like this:
>
>  local point
>  local mt = {
>    __add = function(a, b) return point(a.x+b.x, a.y+b.y) end,
>    ... etc. ...
>
> [...]
> You can only set a metatable for structs/unions or complex/vector
> types (you can wrap other types in a struct, if needed). The
> metatable can only be set once for each type. It automatically
> applies to all instances of this type. Neither the metatable nor
> the __index table must be modified afterwards. The names of the
> declared fields have precedence; __index and __newindex will only
> be consulted if the key doesn't match a declared field name.
>
> Would that work for your use case?

Hi Mike,

I cannot give the answer for the others but for me your proposition is
excellent. I'm actually waiting to have metatables for cdata since
some time, for me is inevitable as it was inevitable to add a gc
metamethod.

I remark also that cdata and userdata converges more and more and we
can wonder if userdata is not going to be redundant with a full FFI
implementation that support metatables. The problem would be that
there is no formal C API for cdata but the logic solution would be
that we unify cdata and userdata and the userdata C API will became
usable. This would allow to mix both Lua+FFI modules and pure C
implementations in the old style.

For GSL shell I've adopted luaJIT2+FFI but I've still a lot of C
implementations that use userdata and I'm forced to perform a lot of
gymnastic to make userdata & cdata live together.

I'm also wondering if Lua itself, in term of language design, should
not take into account the FFI interface since more and more Lua
applications are adopting FFI. The risk here is a fork between two
implementations that are no more compatible.

-- 
Francesco