Re: FFI and Objective C

[Eric Wing <ewmailing@...>]

On 11/23/16, Chris Jones <cmsj@tenshu.net> wrote:
> Hey Eric
>
> On 23 November 2016 at 14:08, Eric Wing <ewmailing@gmail.com> wrote:
>
>> My only thinking here is it would be nice if we could make it easy for
>> somebody to switch back to 5.1. Though honestly, at this point in
>> time, I don't expect there to be many changes in LuaCocoa and I don't
>> really expect anybody new to ask for 5.1 at this point.
>>
>
> I think it could mostly all be handled with #ifdefs. Your call - I don't
> ever plan on going back to 5.1, but I know a lot of people do still use it.
>


I’m fine with #ifdefs for this. The default path can be Lua 5.3.



>> This protects you in case something throws an exception on the system
>> when you are in a pcall. This could happen if either a user or system
>>
>
> Oh that's very cool! Thanks for the explanation :)
>
>
>> One additional thought, I would like to try to stay as close to the
>> Lua 5.3 default definitions as possible (just to simplify people
>> having to remember what definitions were used). I don't think
>> LUA_COMPAT_MODULE is a default, so it might be nice to work towards
>> removing this.
>>
>
> So I set that mainly so it would make the changes to luaL_register() call
> sites as small as possible. If I understand LuaCocoa correctly, the various
> Function/Selector/Struct/Subclass parts of the code, use luaL_register()
> (and now luaL_openlib()) to layer up a single "LuaCocoa" table with all of
> their functions.
>
> This could certainly be done in other ways - possibly the simplest being to
> pull over the functions that LUA_COMPAT_MODULE includes, to LuaCocoa's
> source.
>
> I'm not sure I grok the complete mechanisms going on there, to rewrite the
> Function/Selector/Struct/Subclass code to do this in a different way, but
> as with the 5.1 compatibility, it's your project, so I defer to your
> judgement :)
>
> Thanks very much for your feedback!

Removing the need for LUA_COMPAT_MODULE is a ‘nice to have’. A pipe
dream of mine is that LuaCocoa could eventually just use the stock Lua
distribution and do something like require(‘LuaCocoa’). The
LUA_COMPAT_MODULE is one more hurdle. So pulling over the functions
into LuaCocoa (and renaming them slightly to avoid duplicate symbols)
certainly sounds like the easiest thing to do. However, this isn’t a
requirement for me and is just another ‘nice to have’. Realistically,
LUA_COMPAT_MODULE won’t likely be a real issue for a long time (Lua
5.4?). But if you feel inclined to implement this, don’t let me stop
you :P

Thanks,
Eric