 |
lua-l archive |
|
|
||
|
This is precisely what I do in Hydra[1]; rather than bridging ObjC
using its dynamic capabilities and allowing the user to use it
directly, I just wrap plain old ObjC calls in really simple Lua
methods. Having used (and written) bridges to Objective-C in the past.
It's much, much easier to maintain and to debug.
[1]: https://github.com/sdegutis/hydra/
> 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
>
>