If you were writing rigorous financial applications, I would hope you were
doing enough testing and checking that things like that didn't happen in the
first place.
You shouldn't be lazy and rely on the language to correct your mistakes.
Strong typing only gets in the way (w/ PHP at least), especially since input
validation should consist more than just checking the datatype.
Cheers
-------------------------------- - -- - - -
Philip Murray - Senior Systems Engineer
[EMAIL PROTECTED] - Open2View.com
http://www.open2view.com
------------- - -- - -
----- Original Message -----
From: "Dr. Evil" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 13, 2001 1:43 PM
Subject: [PHP] The need for strong typing...
>
> 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]
>
>
--
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]
