If someone's life is on the line, then defensive programming in one
place isn't going to be the special part that makes it all work. You
should be designing your system as fail-safe -- that is, if something
DOES go wrong, then it should fail in a way that doesn't wind up with
a dead guy on your hands.
Indeed, and part of that design includes extensive cross-checking, including checking for garbage (in the generic sense) at all levels. You are correct that it’s ok to say “garbage in, garbage out” for a given API as part of the contract, but that implies that *somewhere* in the system is code that is absolutely making sure that the API *doesnt* get garbage as input.
At present, the Lua table API has a “garbage-in, garbage-out” philosophy for sequences. But the language provides no easy way to validate sequences, and I think that’s a hole. Yes, I can write a reasonably efficient one in C (at cost O(n)), but it can’t be as efficient as one baked-into the table library, which can leverage it’s internal knowledge much better than code that must use the C API.
—Tim
|
