Re: Locking Table Member Additions

[Tom N Harris <telliamed@...>]

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>