RE: Locking Table Member Additions

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

Thanks Tom.

Thanks for the info.  I'll have to do further review of metamethods.

Rick Leinen
Engineering Manager, R&D Projects
  
Lighting and Energy Solutions

T: 503 404-5561 F: 503 404-5661 C: 503 860-6305
  



-----Original Message-----
From: lua-l-bounces@lists.lua.org [mailto:lua-l-bounces@lists.lua.org] On Behalf Of Tom N Harris
Sent: Monday, June 16, 2014 10:29 PM
To: lua-l@lists.lua.org
Subject: Re: Locking Table Member Additions

On Monday, June 16, 2014 07:05:57 PM Tim Hill wrote:
> On Jun 16, 2014, at 5:50 PM, Sean Conner <sean@conman.org> wrote:
> >  But a question: why?  Adding members should not affect your code, 
> > and it would allow the programmer to associate additional information.
> 
> I would guess the OP does not have full control of the Lua script and 
> wishes to limit what it can do.

Would such a restriction be helpful even if it could be achieved? It's good for an environment to stop a user from shooting himself in the foot. Otherwise you end up with "rm -rf /" situations. Rick wants to be able to guarantee the validity of the table. This is the XML approach. A defensive strategy would not trust that the table is valid and always check it before dispatching to the CAN. HTML5 does not assume anything about the input stream but promises that if there are errors the rendering will fail gracefully and predictably.

But you should always validate your inputs. The functions that use the table need to verify that required fields exist and foreign fields are either ignored or rejected. If you're going to be checking for that anyway, what value is there in being preventative? You're redundantly checking for things at creation time that will be checked again when the table is used.

The approach I would take is to have meaningful defaults. You don't need to pre-fill the table if a missing field is assumed to have a standard default value. You can even use an __index metamethod to return the default value for defined fields.

--
tom <telliamed@whoopdedo.org>