Swig Lua Draft

wiki

Swig/Lua DRAFT

comment excerpts from work in progress

Multi-stage module loading

One Lua motto is "mechanisms, not policies". As a matter of fact, Lua does not come with a predefined object model. Instead, it provides a thin layer of syntactic sugar (: and self) and a small set of powerful mechanisms (environments, metatables, closures and coroutines), that together allow a wide range of object flavours.

Since this is the Lua way, we must follow it in designing SWIG/Lua. This means we must provide flexiblity at some level between SWIG and Lua. On the other hand, we should take care not to make Lua too different from other SWIG target languages with respect to their module interface, which whould decrease reusability.

SWIG does offer a lot in terms of flexibility, but relying on SWIG typemap and directive tricks would clutter interfaces. In also involves writing some C, which is not what SWIG and Lua users are usually interested in !

This leads to the natural solution of implementing Lua-side wrapping specifics in Lua itself [1].

We offer the following basic mechanisms:

• 1) loading: load spec chunk + runtime library.
• 2) linking: resolve wrappers in spec.
• 3) mapping: match spec with a templated logical module map.
• 4) exposing: generate proxies and their metatables.

Stages 1 and 2 are straightforward. Stages 3 and 4 rely on declarative techniques for clarity and power.

[1] By contrast, the current official implementation of SWIG/Lua uses a single arbitrary object scheme that is hard-coded in C somewhere in the runtime SWIG library. Yes, the resulting modules can still be tweaked, but high-level information is already lost, and that is a brittle approach.

Comments welcome.