undefined | Better HN

0 pointssdegutis11y ago0 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.

0 comments

3 comments · 1 top-level

cbsmith11y ago· 2 in thread

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.

sdegutisOP11y ago

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

cbsmith11y ago

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.

1 more reply

j / k navigate · click thread line to collapse