As you know, gases such as oxygen and acetylene are distributed to
welders in pressurized containers. As you can guess, it is very
important to put the right stuff in the right container. Let's say
you have a container of acetylene, and you accidentally top it up with
some pure oxygen. This is likely to be a life-altering exerpience,
and not in the New Age chanting-in-a-sweat-lodge sense if you know
what I mean.
The naive solution to this problem is to put a big sign up that says,
"Warning: be very careful about which gas you put into which tank."
I'm sure that was the first approach that was tried when pressurized
tanks for welding were first developed. After a few people died by
putting the O2 in the C2H2 tank, someone came up with a brilliant
solution: Let's put reverse threads on the O2 tank attachments. That
way, the tank, and all the hoses and connectors that go with it, can
never be attached to a C2H2 tank, because of a physical contraint in
the connections themselves. O2 uses left-hand twist and C2H2 uses
right-hand twist, and so the two will never meet. No matter how
asleep, negligent, or incompetent the filling operator is, he'll never
end up with O2 in the C2H2 tank. Even the sharpest, most cautious
tank filler will eventually make a mistake if he does it enough times,
but never if the threads are reversed.
Data structure contraints are exactly the same idea. In my DB I have
a table for "payments". Every time Alice pays Bob, a row gets added
to this table, with one of the columns being "amount of transfer". Of
course, on the PHP side, I put in a check:
if($amount <= 0) { // error condition }
but, in addition to that, in the database itself, I have
CONSTRAINT amount > 0
built into the table definition. That way, no matter what goes wrong
on the PHP side, Bob will never be able to say, "Pay alice -$1mil",
and find his account $1mil richer. The value is checked (several
times) in the PHP side, but the right behavior is built into the data
structure (table) itself.
Strong typing is a sort of constraint. Just like I don't want to be
using O2 when I think I'm using C2H2, I would like to be sure that
I've got an INT and not a STRING when I expect an INT. Saying "write
a bunch of functions to check user input, and don't make any mistakes"
is just like putting up a sign that says, "Be very careful to not put
O2 in the C2H2 tank." Yeah, if I were perfect, that would be enough,
but in the real world, when you're dealing with serious things like
exploding tanks and money, you want some built-in constraints in the
system. You want correctness to be enforced at several different,
independent layers.
This same design principle applies in many different realms: my
motorcycle has completely independent front and rear brakes, so even
if one system fails entirely, I can still stop. My Glock has three
independent safety systems (trigger block, firing pin block,
decocking) which must each be operational for it to fire. It's just
good design to have redundant constraints to achieve high reliability
and safety. Strong typing is one of those contraints.
This doesn't mean that PHP should be changed to allow strong typing.
It may mean though that PHP isn't the right language for rigorous
applications like financial transactions.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
