Re: Locking Table Member Additions

[Sean Conner <sean@...>]

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.