Peter Cawley | 2 Jun 03:47 2012

FFI Reflection

As FFI reflection / introspection is a topic which has come up a few
times, I've taken a stab at writing a little library which uses the
FFI to provide information about FFI types. I've only tested this
against LuaJIT2 beta 10 on Windows x86, so it has the potential to
break elsewhere. I currently consider the library to be beta and
experimental, so if it is of interest to you, I'd welcome any feedback
on how it should be changed and/or what else it should do.

Code: http://www.corsix.org/lua/reflect/reflect.lua
Documentation: http://www.corsix.org/lua/reflect/api.html
Tests: http://www.corsix.org/lua/reflect/test.lua (generated from the
documentation)
All of the above: http://www.corsix.org/lua/reflect/beta1.zip

James McKaskill | 2 Jun 04:07 2012
Picon

Re: FFI Reflection

On Fri, Jun 1, 2012 at 9:47 PM, Peter Cawley <corsix@...> wrote:
> As FFI reflection / introspection is a topic which has come up a few
> times, I've taken a stab at writing a little library which uses the
> FFI to provide information about FFI types.

Large API. Honestly what is the main requirement for a reflection API.
Do you really need information on the calling convention of a
function, etc. or do people just want to iterate over the members of a
struct?

-- James

Kaj Eijlers | 2 Jun 04:26 2012
Picon

Re: FFI Reflection


Large API. Honestly what is the main requirement for a reflection API.
Do you really need information on the calling convention of a
function, etc. or do people just want to iterate over the members of a
struct?

-- James

Well, that would really depend on the use case, no? If you want to do metaprogramming (or rather validation of generated/imported code) I'd say the more info the merrier. Basically, if it can be exposed I don't see why you wouldn't reflect it - I'd rather have too much info available than too little.

James McKaskill | 2 Jun 04:39 2012
Picon

Re: FFI Reflection

On Fri, Jun 1, 2012 at 10:26 PM, Kaj Eijlers <bizziboi@...> wrote:
> Well, that would really depend on the use case, no? If you want to do
> metaprogramming (or rather validation of generated/imported code) I'd say
> the more info the merrier. Basically, if it can be exposed I don't see why
> you wouldn't reflect it - I'd rather have too much info available than too
> little.

Larger API = harder to change implementation, more code, more bugs, etc

I'm looking this from the other way. I have no real need to use the
API, but I'm thinking of what would be required to get luaffi to
support it as well. There are aspects of that API which I couldn't
support off the bat. For example luaffi subsumes anonymous
structs/unions at parse time so

struct {struct {int a;};};

is the same after parsing as:

struct {int a;};

Also having a better idea of its intended use cases can focus more on
that aspect.

-- James

Alexander Nasonov | 10 Sep 20:51 2013
Picon

Re: FFI Reflection

James McKaskill wrote:
> I'm looking this from the other way. I have no real need to use the
> API, but I'm thinking of what would be required to get luaffi to
> support it as well.

Sorry for bringing up 1yo topic but I needed/wanted to use FFI
reflection in a pure Lua environment and it didn't work.

I wonder if you guys thought about intergrating your work and supporting
reflection with luaffi package?

Thanks,
Alex

Kaj Eijlers | 2 Jun 05:04 2012
Picon

Re: FFI Reflection

I'm looking this from the other way. I have no real need to use the
API, but I'm thinking of what would be required to get luaffi to
support it as well. There are aspects of that API which I couldn't


That is actually an interesting way of evaluating an API, I see where you're coming from. Imo, use cases of reflection/introspection are hardly classifiable as they tend to open up the language instead of adding to it. It`s typically an area where unexpected awesomeness can happen - it it isn`t limited. 
Alek Paunov | 2 Jun 15:09 2012

Re: FFI Reflection

Great start! Thank you!

I suppose that FFI+Refletion will serve as basis for bunch of new, cool 
serialization tools [*].

Personally, I am going to utilize the API for a several experiments with 
the sqlite bytecode (VDBE [1]) next weekends ;-).

Kind Regards,
Alek

[1] http://www.sqlite.org/cgi/src/artifact/87b8ff40?ln=37-75

[*] LuaJIT FFI+Reflection means possibility of the light, easy, 
efficient and portable serialization of the native data structures to 
the current message formats. (actually, the first *really* easy and 
right solution for real life C data graphs AFAIK).

IMO, this feature gives the practical chance for the users of many 
proven C libs to evolve and expand their cases according today's message 
oriented designs.

I am very optimistic about the above application popularity, once the 
first "cool" sample makes his way to the "front pages" :-).

William Adams | 2 Jun 21:23 2012
Picon

RE: FFI Reflection

KICK ASS!!
 
One of the best features I liked about Objective-C when it first really hit the scene (with NeXT computers) was method forwarding.  Lua has __call metamethod, and having reflection just gives you one more interesting tool to use.
 
For me, the use cases fall into two categories,
serialization
invocation
 
At this moment, having the maximum capabilities seems better than going skimpy trying to satisfy a particular scenario.  Over time, obvious uses will emerge, and the interface can evolve and mature, but it's adolescent, so I'd say, just let it run free and wild.
 
One interesting use case that mixes serialization and remote invocation is taking the function call information (along with the data structures) and automatically creating a serialized remote invocation call.  Take a drawing package, based on GDI or OpenGL perhaps.  Given the specifications in C, I can now automatically generate a package that encapsulates a function call, sends it across to someone, they can unpack it, and call the function.
 
I don't have to write any code on either end to do this (other than the C declarations, which already exist in the header).  And, given the size of these APIs, that's a huge win.
 
Keep up the great work!
 
-- William

===============================
- Shaping clay is easier than digging it out of the ground.
http://williamaadams.wordpress.com
http://www.thingiverse.com/WilliamAAdams
https://github.com/Wiladams
 
> Date: Sat, 2 Jun 2012 16:09:50 +0300
> From: alex-jUE9FD3ILm5BDgjK7y7TUQ@public.gmane.org
> To: luajit-uGLqWuYN4qMgsBAKwltoeQ@public.gmane.org
> CC: corsix-F2hBSiM+zxwdnm+yROfE0A@public.gmane.org
> Subject: Re: FFI Reflection
>
> Great start! Thank you!
>
> I suppose that FFI+Refletion will serve as basis for bunch of new, cool
> serialization tools [*].
>
> Personally, I am going to utilize the API for a several experiments with
> the sqlite bytecode (VDBE [1]) next weekends ;-).
>
> Kind Regards,
> Alek
>
> [1] http://www.sqlite.org/cgi/src/artifact/87b8ff40?ln=37-75
>
> [*] LuaJIT FFI+Reflection means possibility of the light, easy,
> efficient and portable serialization of the native data structures to
> the current message formats. (actually, the first *really* easy and
> right solution for real life C data graphs AFAIK).
>
> IMO, this feature gives the practical chance for the users of many
> proven C libs to evolve and expand their cases according today's message
> oriented designs.
>
> I am very optimistic about the above application popularity, once the
> first "cool" sample makes his way to the "front pages" :-).
>

Gmane