Re: The need for strong typing...

I was going to write a whole diatribe, venting rage, trying to prove you wrong etc, etc... and then I got to the last paragraph and realised we probably actually agreed:

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.

The main problem with the Oxy-Acetylene analogy is that there is very little that anyone does with PHP that could even vaguely be considered life threatening - in most cases the worst case scenario is that if something goes wrong, someone will get a bit annoyed. Even with financial transactions - an error going wrong there is really BAD, but generally it CAN be tracked down and fixed, and no one is going to die as a result. This has always been a problem with Software - it has never truly been "component" based. On some level it is always like being given the same ball of string to solve every problem, whether it be a fence, a clothesline, or an inter-planetary catapult system. Anyway - you talked about having a series of hurdles for things to get past. So, "strong typing" has been removed as a hurdle - fine, lets just add in a few more like "rigorous testing" and "rigorous code reviews" and "careful design" and "rigorous design reviews". The MOST mission critical software ever written is, I think, the software that controls the space shuttle as it gets launched. Once the final ignition sequence goes off, nothing can stop it and the only thing controlling it is the software. That graceful takeoff and roll it does on takeoff would be impossible for a human to control. That software is as close to bug free as you will ever get. It is also incredibly expensive because EVERY change is reviewed, analysed, studied and tested incredibly thoroughly to review it's impact and to make sure it will have no roll on effects. At 01:43 13/07/2001 +0000, Dr. Evil wrote:

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: php-general-unsubscribe@lists.php.net For additional commands, e-mail: php-general-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net

------------------------- Brian White Step Two Designs Pty Ltd - SGML, XML & HTML Consultancy Phone: +612-93197901 Web: http://www.steptwo.com.au/ Email: bwhite@steptwo.com.au