Re: Locking Table Member Additions

[Paige DePol <lual@...>]

On Jun 17, 2014, at 6:15 PM, Tim Hill <drtimhill@gmail.com> wrote:

> On Jun 17, 2014, at 3:42 PM, Andrew Starks <andrew.starks@trms.com> wrote:
> 
>> 
>> Couple of things to note. Byte-for-byte, compiler Lua code is very compact. You might find the Lua code to build the table is smaller than the equivalent C code. As others have noted, you might be better served by validating the table when passed to a C function, rather than trying to lock it down proactively (again, probably less code overall to do this).
>> 
>> —Tim
>> 
>> 
>> 
>> I understand the sentiment of the OP. When we started to write our first Lua C-API code, we wrote way too much in C. As time has gone on, we've replaced all of that. It's much easier to build up models and abstractions in Lua and it does not make any difference, for speed. 
>> 
>> It is hard to let go. It was also hard for our C++/C guy to really *get* the dynamic stuff. He would error when I set an unexpected value on a table, for example. 
>> 
>> We've fallen into a nice routine where he is working in C and I'm in Lua and we both end up learning valuable things about the interactions between the two.
>> 
>> -Andrew 
>> 
> 
> Yep, been there, done that :)
> 
> These days, I explain it to my team as “Lua=Brain, C=Muscle” .. do compute bound stuff in C but with no policy. Move business and policy logic to Lua.
> 
> —Tim

Great explanation, Tim!

That is exactly what I aiming for with ONiA and Lunia... ONiA being my game engine and Lunia being my Lua variant. :)

~pmd