 |
lua-l archive |
|
|
||
|
On 11/07/2014 4.10, Steven Degutis wrote:
I'm also quite disillusioned about such bridges in the first place, having come to the same conclusion that Apple apparently has (as they've deprecated all bridges and made NSInvocation inaccessible via Swift), namely that bridges between even mildly disparate programming languages are inherently broken and should be avoided except in the rarest of prototypical cases.
One trick I use to build robust bridges is to avoid 1:1 connections.For example, if I have a game engine made of C++ classes, I do not replicate those classes on the Lua side (e.g. by mirroring classes, fields, methods): I may as well use C++ only and avoid dual-language troubles. Instead, I design a Lua API that makes sense for a Lua programmer and connect it to the C++ side using as narrow a bridge as possible.
This type of bridge has a higher development cost, is application-dependent and is (usually) harder to automate, but it helps in decoupling the two sides, both from a programming and from a conceptual viewpoint: the C++ programmer thinks in engine terms and the Lua programmer (who could be the same person with a different hat) thinks in application domain terms. A narrow language bridge is also easier to adapt to structural or libraries changes on either side.
-- Enrico