[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Locking Table Member Additions
- From: Tom N Harris <telliamed@...>
- Date: Tue, 17 Jun 2014 01:28:33 -0400
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>