RE: Locking Table Member Additions

["Leinen, Rick" <RLeinen@...>]

-----Original Message-----
From: lua-l-bounces@lists.lua.org [mailto:lua-l-bounces@lists.lua.org] On Behalf Of Sean Conner
Sent: Tuesday, June 17, 2014 4:04 PM
To: Lua mailing list
Subject: Re: Locking Table Member Additions

It was thus said that the Great Andrew Starks once stated:
> On Tue, Jun 17, 2014 at 5:26 PM, Tim Hill <drtimhill@gmail.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).
> >
> 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.

  Same here.

  At work, the test tool I wrote is half Lua, half C, and I wrote it in such a way that the Lua API mimics very closely the C API, to the point where you could nearly mechanically translate the Lua into C (the API mimicry is that
close) in case the Lua side proved too slow.

  It never proved too slow [1] and half the time I'm wanting to just rip the C code out [3].

  -spc 

[1]	We hit other restrictions, like number of outstanding messages and
	slow and hilariously fragile communication links [2].

[2]	SS7 crap.  If what we're using is "the SS7 network stack best of
	breed" then SS7 network seriously sucks.

[3]	But it works, and I would have to do some extensive testing of the
	code just to make sure I can test the code I'm supposed to test.

Andrew/Sean,

Thanks for the perspectives.

Rick