You might be able to do a lot of the same stuff in AppleScript, but that's AppleScript and this is Lua, which to me personally is a huge advantage.
And it's not quite a Lua "scripting bridge". That term usually implies automatic bridging between two programming languages, such as Lua and Objc, but all our bridging is manual.
The "Scripting Bridge" is a way to tie any language in to the Apple Event messaging architecture. I guess you can think of it as bridging Lua to Objc, but it is much more language agnostic than that. This is how you can have automation scripts on OS X writing in Ruby/Python/JavaScript/etc.
I get that your bridging is manual, but if you built on top of the scripting bridge you'd have something much more general, and your "manual" bridging could just be pure Lua code.
Having used "Scripting Bridge" for a few years now, I'm keenly aware of its very real and common caveats, and I'm not comfortable using it in any serious project. If users would like to write something like Hydra using only LuaObjC[1] or something similar, they're free to. But manually bridging function calls gives Hydra a robustness and stability that such an automatic bridge can never truly have.
I'm sure you wouldn't have bothered with the project if you didn't perceive it as being a better approach. I'm just ignorant to what the advantages are. Is the bridge really unstable? I hadn't noticed that with my admittedly limited exposure.
Comments
You might be able to do a lot of the same stuff in AppleScript, but that's AppleScript and this is Lua, which to me personally is a huge advantage.
And it's not quite a Lua "scripting bridge". That term usually implies automatic bridging between two programming languages, such as Lua and Objc, but all our bridging is manual.
The "Scripting Bridge" is a way to tie any language in to the Apple Event messaging architecture. I guess you can think of it as bridging Lua to Objc, but it is much more language agnostic than that. This is how you can have automation scripts on OS X writing in Ruby/Python/JavaScript/etc.
I get that your bridging is manual, but if you built on top of the scripting bridge you'd have something much more general, and your "manual" bridging could just be pure Lua code.
Having used "Scripting Bridge" for a few years now, I'm keenly aware of its very real and common caveats, and I'm not comfortable using it in any serious project. If users would like to write something like Hydra using only LuaObjC[1] or something similar, they're free to. But manually bridging function calls gives Hydra a robustness and stability that such an automatic bridge can never truly have.
[1] https://github.com/darrenclark/LuaObjC
I'm sure you wouldn't have bothered with the project if you didn't perceive it as being a better approach. I'm just ignorant to what the advantages are. Is the bridge really unstable? I hadn't noticed that with my admittedly limited exposure.
I'm just weary of any bridge to ObjC, having seen the caveats first-hand. But I suppose it's mostly just in principle.