lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]





On Fri, Jul 11, 2014 at 8:40 AM, Steven Degutis <sbdegutis@gmail.com> wrote:
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 Fri, Jul 11, 2014 at 2:21 AM, Enrico Colombini <erix@erix.it> wrote:
> 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
>
>

disclaimer: This is our first go around at integrating Lua into our software and while I work with an experienced C++ programmer, I'm not experienced in C or C++... 

We're building for Lua 5.3 (and are happy to deal with the changes, as they come). Once it's released, we're only going to care about 5.3.X stability. 

As we circle back and open source the code that may be a candidate for use as a module, we'll have to deal with 5.1/5.2/LuaJIT, but beyond that, why would we want to support every version of Lua in the wild, when we're only using one version of Lua in the project?

Making it *easy* (free) for me to migrate from one Lua to the next is a feature, and the word "feature" implies quite a lot. I'm skeptical of backwards compatibility and I think that the evidence is there to support the belief that it can only be taken so far.

My stab at categorizing the complexity cost of backwards compatibility:

1: I see it and it's historical: Deprecated or overlapping methods/functions that my old code may use, but that I'm not using in new code, which helps me from not having to patch old code or create bridges to old code. _javascript_ comes to mind, due to the "Don't Break the Web" mandate. The "bridging" code moves from "my problem" to the implementation's problem and the weight of it is felt by everyone, forever.

2: I see it but it doesn't have a benefit to the actual goal: An interface that has lots of conventions I have to follow that are there to support extensibility.

3: I don't see it, but it's there and it leaks through: Performance is a bit slower, error messages are a bit more obfuscated, the Language implementation is less stable, even though the interface isn't.

I don't think there is a number 4 "It's there but I never see it and it's free", very often.

On approach to binding:

We've generally found that the conceptualizations of the domain (application abstractions) expressed in C / C++ end up exploding the amount of required code, overall. Or, another way to express that is: There are very few favors that you want from C, when you're in Lua. It seems to end up that those "favors"/abstractions have to be broken down and rebuilt and so, what is the point?

In PiL, it says that Lua errors should always be presented in terms of the application, not in system terms. Lua shouldn't crash the whole program.

We had been following that principle, but we've recently moved that line. Instead of saying that Lua shouldn't crash the whole program, we're saying that the user's Lua scripts shouldn't do that. Much of the binding is written in Lua and some of those operations (management of thread/memory/other resources) have the potential to crash the application.

-Andrew