Ticket #462 (assigned planned)
Lua integration: register existing functions
| Reported by: | nasa | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | 1alpha |
| Component: | lumiera | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: | #134 |
Description
Create header file(s) as per ( http://www.lua.org/pil/26.2.html) which contains the backend, proc, and gui functions accessible from lua.
Change History
comment:2 Changed 20 months ago by ichthyo
the problem here is not so much to map individual functions, rather it is common practice today to cast interfaces in terms of objects. We might or might not discuss if tha's a good idea, but anyway, its the expectation we meet, when we intend to provide a "scripting interface". So even it the initial access point is just a function in the core, the arguments are what causes the real problem with any script binding.
The special twist here is:
- core returns an object as result of an API call, where the actual implementation class of the object remains opaque
- core expects the scripting client to provide an object implementing an interface, where the actual implementation class remains a private detail of the script
- we need to bridge memory management: script languages have typically automatic means of dealing with instances, and the core as well has an mostly automatic facility; both need to be linked together somehow.
The typical solution is to have proxy objects as a counterpart (either in the core or in the script engine, depending on the direction of the collaboration).

The initial plan was to use the 'interfaces' facility and maybe luaffi to bind C functions instead wrapping each function directly. This would also be a nice excercise to find out if we need to refine the interface framework (maybe remove uuids, add function signatures, ...)