lua-users home
lua-l archive

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

On 10/6/09, David Given <> wrote:
> E. Wing wrote:
> [...]
>> Meanwhile, I patched the existing legacy bridge to be garbage
>> collection aware and fixed up some major memory leaks. I also have
>> been working with pieces from Gus Mueller's LuaCore and added some
>> hand-crafted bindings for the C-parts of Core Animation, though this
>> is all intended as a temporary layer on the bridge. The next-gen
>> bridge at least on Mac should be using Bridge Support (like MacRuby
>> and PyObjC).
> How much of this is OSX-specific? Will it work with GNUstep, for example
> (since I don't have a Mac handy...)

The actual LuaObjCBridge at one point had #defines for both GNUStep
and OS X. However, I don't think the GNUStep side was tested well. And
since then, in order to squash serious bugs (like the ones in my last
post), I crossed the #define barriers in several occasions and may
have broke things. (The CFRetains and CFReleases would be one of those

LuaCore is more OS X specific as it provides mostly manual bindings
for C functions and structs. The ones like NSRect/NSPoint/NSSize might
be salvageable though I may have been too clever and may have tried to
do some toll-free like bridging with CGRect/CGPoint/CGSize which would
need to be removed. You would also need to remove bindings for things
like Core Graphics and Core Animation. But LuaCore is not required to
use LuaObjCBridge.

> Also, how much introspection can you do on a bridged object? Do you see
> them simply as opaque Lua objects with method calls peered over to
> Objective C, or does the full Objective C class hierarchy appear in Lua,
> which you can then add classes to, etc?

I think they are opaque. This is more of an implementation detail more
than anything else. The original bridge used actual tables and user
lightdata for objects instead of full user data. When I switched
things over, it really became a hybrid of things so it was hard to
peer into anything. My intent would be to completely fix this in the
next-gen bridge.

>> We still lack a good object model. From the one minute I've seen of
>> Objective Lua, it is very compelling. Is the translation done all
>> through Lua (no C)? If so, this reminds me a lot of Objective-J and
>> what the 280 North folks did to Javascript for their web based
>> application framework called Cappuccino.
> About a minute is all it's worth; right now the Objective Lua 'compiler'
> is an almost trivial syntax hack. The object model is a traditional
> metatable-based Lua OO system. The only thing slightly interesting about
> it is that it supports class methods. In fact, it's currently all wrong,
> and I need to rewrite it. I think I've got a fairly simple design that
> can support categories.

Simple (and elegant) is great. That's what Lua is about, right? I'm
probably the wrong person to be maintaining the bridge, so simple is
perfect for me :)

> I didn't know about Objective J; it's rather interesting, and very much
> the same sort of thing. In fact, I might steal some of their syntax.
> There's been a surprising amount of interest. (The reddit link didn't
> help...) In the past 24 hours that one page alone has had 3300 hits. I
> usually get about 2000 hits a month *on my entire website*! Admittedly,
> only 36 actual code downloads, but it's certainly striking a chord with
> people. Maybe it *would* be worth doing properly...

I've attended a couple talks given by the folks from 280 North (who
did Objective-J) since they are local to me. It's very interesting
stuff and it's interesting to hear the feedback they hear from
Javascript users.

I think your Objective Lua idea is terrific. And borrowing ideas from
Obj-J would be smart since they've already been down this road.

I would really like to see Objective Lua adopted into a Lua/Obj-C
bridge (assuming that it is a pure superset of Lua is you can still
use normal Lua syntax with it).