Re: Is Lua stable? (Was: Strange Operators (Was: Why I leave Lua (Was: Re: [ANN] Lua 5.3.0 (work3) now available)))

[Steven Degutis <sbdegutis@...>]

Hi Eric.

Thanks for the reply. I understand where you're coming from in wanting
more flexibility in the API and in Lua itself. I especially understand
it having written a few ObjC bridges myself, being no stranger to
NSInvocation and family.

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.

Though I admit that I'm still tempted now and again to add an `objc`
module to my application so its users may have a shortcut to trying to
build things I had not imagined or gotten around to yet or agreed
with. But it takes little more than remembering how much complexity I
would then need to support in future versions and in bug reports to
dissuade me.

Thus it should come as no surprise when I disagree about the strength
of an argument for increased complexity based solely in supporting
such bridging tools.

On Thu, Jul 10, 2014 at 8:16 PM, Eric Wing <ewmailing@gmail.com> wrote:
> On 7/10/14, Steven Degutis <sbdegutis@gmail.com> wrote:
>> Hello again.
>>
>> As I mentioned in other posts, I've recently started embedding Lua
>> into my Objective-C (OS X) applications. Besides my short stint trying
>> to use and configure "awesome" (a window manager), this has been my
>> first real in-depth usage of Lua.
>
>> But a very small part of me is concerned that it will continue to grow
>> in breaking ways, eventually adding a disproportionate amount of
>> complexity simply for the sake of continuing to work on it when
>> there's nothing left to work on.
>
> You found my trigger switch. As somebody who wrote a full fledged
> language bridge between Lua and Objective-C (LuaCocoa), I disagree
> with your sentiment that the changes are for complexity sake.
>
> In Cocoa, the main integer type is NSInteger/NSUInteger which is
> 64-bit under Apple's 64-bit architectures and caused a lot of pain
> points for me for bridging, particularly when APIs use max int as a
> sentinel value. In 5.1, I resorted to the LNUM patch and was kind of
> stranded in 5.2. I am so happy that Lua 5.3 is getting integer
> subtypes. This is a killer feature for me (that go well beyond just
> LuaCocoa as I'm also in video games and performance matters).
>
> In Lua 5.2, __pairs and __ipairs became accessible. I have been very
> interested in bridging Lua's iterators with Obj-C's fast enumeration
> feature. It never made sense to me why there was no metamethods for
> these. Now that's fixed.
>
> One thing I still would like to see is Lua's exception handling
> (implementation detail) refactored in a way that allows me to more
> easily change it so I can make it use Apple's Obj-C @try/@catch
> exception mechanism without compiling all of Lua as Obj-C.
> http://lua-users.org/lists/lua-l/2012-04/msg00722.html
>
> Apple's exception system has really nice benefits on their platform
> because it is zero-cost try and also unified with C++ exception
> handling (but doesn't require you to compile anything as C++). And it
> allows pcall to trap any exceptions thrown in a native framework.
>
> In fact, it makes so much sense, I really think there should be a
> default convenience implementation shipped in Lua that is on by
> default when compiling for Mac or iOS.
>
> But as it stands now, I have to figure out how to refactor a bunch of
> things in Lua every time there is a new release. I'm tired of that
> busy work.
>
>
> Thanks,
> Eric
> --
> Beginning iPhone Games Development
> http://playcontrol.net/iphonegamebook/
>