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 Tom N Harris
Sent: Tuesday, June 17, 2014 3:42 PM
To: lua-l@lists.lua.org
Subject: Re: Locking Table Member Additions

On Tuesday, June 17, 2014 05:29:14 PM Sean Conner wrote:
>   It's a bit involved, as you need to handle both __index and 
> __newindex in C.  You can see an example here:

In this instance, I don't think the table necessarily needs to be exposed as a table. A simple functional interface would suffice and be less confusing with regards to what parameters are allowed.

    messagePayload:setRelativeLevel(false)
    print( messagePayload:Priority() )
    messagePayload:addDimmer {dim=1, lev=128}

On the other hand, a table-like interface uses less Lua memory. Each function in a metatable is a name, closure, and hash table entry. Using the userdata as a table only creates two closures and the names, while pushing the time and memory onto the C side.

That said, it'll take a very large script to put a dent into 256M. What I said about defaults allows you to save a few bytes by not needing to type every field name and value. But Lua's string interning, efficient storage of numbers, and constants in the prototype do most of the work of keeping memory usage reasonable.

Of course the mantra we all must remember is "no premature optimization". This applies to space as well as time.

--
tom <telliamed@whoopdedo.org>


Tom,

Your function method dawned on me earlier today, but I agree that the overhead is not attractive.  I'm coming to the conclusion, based on feedback from this listserv, that I need to back off my concern and provide adequate testing on the C side in case somebody does something unexpected.  I will explore the userdata idea some more.

One thing I neglected to mention is that the scripts are to be kept in the Kintetis' internal 256K data flash.  While the parsed script should be small, the source script can get large, especially if more than one is used.

Your "no premature optimization" mantra gave me a chuckle.  A few years ago I served as the technical specification lead on a new product line.  The lead firmware engineer and I would debate on how certain things should be done.  So often he would tell me that my idea was an optimization and that he would deal with those later.  Well, they never did get dealt with, and though the product is rock solid and provides the functions asked for, it is still plagued with inefficient operation; some more obvious than others.  It can be a difficult balance to maintain.  :-)

Rick