RE: [PHP] The need for strong typing...
I was going to suggest this too. I like doing any sort of transactions or complex business logic using components whether they be servlets, com objects, etc. I would take advantage of the ability to integrate different technologies. Also, it helps using a compiled language for the bus logic, because a designer (for example) couldnt "accidentally" open your page in a wysiwymg editor and kill parts of your app. my addt .02 q. -Original Message- From: Opec Kemp [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 12, 2001 9:17 PM To: Dr. Evil Cc: PHP List Subject: RE: [PHP] The need for strong typing... > I will look into JSP. > > Even on the same website, we could have two different languages: Maybe > we'll use JSP for the transaction stuff, and PHP for customer support > pages, where things are less critical. Incidentally, PHP4 can also use some Java Serverlet or Bean. Check out this bit from the manual: http://www.php.net/manual/en/ref.java.php This PHP/Java combo could be what you needed :) -- 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]
RE: [PHP] The need for strong typing...
you could easily write yourself a typing function to take care of all that (as someone suggested previously) using the same familiar syntax as you want to use in the function definition. function pay($fromaccount, $toaccount, $amount, $memo) { $good = checkInput($fromaccount, "int", $toaccount, "int", $memo, "varchar(1000)" ) or die("Invalid input!"); // code... } > -Original Message- > From: Dr. Evil [mailto:[EMAIL PROTECTED]] > Sent: Thursday, July 12, 2001 10:31 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: [PHP] The need for strong typing... > > > > The one problem with all your musings is that there is no such thing as an > > integer when it comes to transferring data over http. Everything comes as > > a string. What is done with these strings when they get to the > > application is what matters. It's not like there is an HTML form element > > like or . All you have is > type=text> when it comes to users entering data and passing it to you. I > > fail to see how strong typing helps you here at all. You are going to > > have to apply some sort of user-space rule once you receive the data. And > > that is quite easy to do with PHP. > > Right, obviously. The only data type in http is the string. However, > there is obviously some value in being able to say: > > function pay(fromaccount int, toaccount int, amount int, memo >varchar(100)) { // > > instead of: > > function pay(fromaccount, toaccount, amount, memo) { // > > In the former case, even if there was a mistake in checking user > input, at least the script will die instead of trying to do some > operation on some impossible data type. That's a good thing. > > Obviously, all user input must be taken from string type to other > types, but internal functions should be constrained. It's just > another level of checking. It's exactly the same reason why databases > allow you to put constraints into table definitions. Sure, you should > check that the value is positive when you do the INSERT, but you > should also put a constraint into the table. Lots of things go > wrong. > > Also obviously, this capability isn't needed for most of what PHP is > used for, and so maybe it doesn't belong in PHP, and maybe those of us > who are writing more sensitive aps should look into other things. Any > sugestions? > > I don't want people to think that I'm bashing PHP. I'm not. I love > it. I could never go back to perl or anything else. It's just that > I'm working on this one particular financial application, and I'm > paranoid that something will slip through somewhere, and I would feel > more comfortable if I could define variables that have built-in > constraints. Can I use classes to do this? > > -- > 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]
RE: [PHP] The need for strong typing...
> I will look into JSP. > > Even on the same website, we could have two different languages: Maybe > we'll use JSP for the transaction stuff, and PHP for customer support > pages, where things are less critical. Incidentally, PHP4 can also use some Java Serverlet or Bean. Check out this bit from the manual: http://www.php.net/manual/en/ref.java.php This PHP/Java combo could be what you needed :) -- 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]
Re: [PHP] 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: Yes, I think so too. Different languages for different things. Even COBOL has a valid reason for existing. In fact, most of my app is written in pl/pgsql, which is a lot like COBOL in that it has very limited capabilities and a very clear syntax and strong typing. It's hard to make mistakes in it. > >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. That's true for old-style financial apps, where a check can be bounced, transactions reversed, etc, but in a modern real-time gross settlement system, errors can be very expensive, and hackers are always on the prowl. Spending $100k to make sure the code is rock-solid is probably cheaper than letting some errors or uncertainties creep through. > 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". Good point. Another point is that this software will not suddenly be used for billion-dollar payments. It will start with a small user base and small values, where mistakes won't be fatal, and then it will grow, and as it grows, there will be more code reviews, design reviews, etc. > 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. Interesting story. Fortunately, financial transactions are actually simpler than shuttle launches. Really, the whole thing consists of: 1. Is the user authorized to make this transaction? 2. Does the user have sufficient funds/credit to make the transaction? 3. Is the recipient authorized to receive the transaction? 4. Lock the sender's account. 5. Check the funds/credit again. 6. Make the transaction. 7. Unlock and inform the user. It's simple, but mistakes are expensive. I will look into JSP. Even on the same website, we could have two different languages: Maybe we'll use JSP for the transaction stuff, and PHP for customer support pages, where things are less critical. -- 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]
RE: [PHP] The need for strong typing...
> Also obviously, this capability isn't needed for most of what PHP is > used for, and so maybe it doesn't belong in PHP, and maybe those of us > who are writing more sensitive aps should look into other things. Any > sugestions? I suppose that if you *really* do need strongly typed language that's widely used (and cross platform like PHP) then you can't get past JSP or Java Servlets. JAVA is definitely a strongly typed languge :). There are other languages out there of course like Python or something but I don't know enough about it to comment. Or run your Perl as Mod_Perl in Apache, IIRC you have to use strict anyway in this mode. My $0.02 -- 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]
Re: [PHP] 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 +, 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
Re: [PHP] The need for strong typing...
> The one problem with all your musings is that there is no such thing as an > integer when it comes to transferring data over http. Everything comes as > a string. What is done with these strings when they get to the > application is what matters. It's not like there is an HTML form element > like or . All you have is type=text> when it comes to users entering data and passing it to you. I > fail to see how strong typing helps you here at all. You are going to > have to apply some sort of user-space rule once you receive the data. And > that is quite easy to do with PHP. Right, obviously. The only data type in http is the string. However, there is obviously some value in being able to say: function pay(fromaccount int, toaccount int, amount int, memo varchar(100)) { // instead of: function pay(fromaccount, toaccount, amount, memo) { // In the former case, even if there was a mistake in checking user input, at least the script will die instead of trying to do some operation on some impossible data type. That's a good thing. Obviously, all user input must be taken from string type to other types, but internal functions should be constrained. It's just another level of checking. It's exactly the same reason why databases allow you to put constraints into table definitions. Sure, you should check that the value is positive when you do the INSERT, but you should also put a constraint into the table. Lots of things go wrong. Also obviously, this capability isn't needed for most of what PHP is used for, and so maybe it doesn't belong in PHP, and maybe those of us who are writing more sensitive aps should look into other things. Any sugestions? I don't want people to think that I'm bashing PHP. I'm not. I love it. I could never go back to perl or anything else. It's just that I'm working on this one particular financial application, and I'm paranoid that something will slip through somewhere, and I would feel more comfortable if I could define variables that have built-in constraints. Can I use classes to do this? -- 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]
Re: [PHP] The need for strong typing...
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]
Re: [PHP] The need for strong typing...
The one problem with all your musings is that there is no such thing as an integer when it comes to transferring data over http. Everything comes as a string. What is done with these strings when they get to the application is what matters. It's not like there is an HTML form element like or . All you have is when it comes to users entering data and passing it to you. I fail to see how strong typing helps you here at all. You are going to have to apply some sort of user-space rule once you receive the data. And that is quite easy to do with PHP. For your specific example you simply want to use the is_numeric() function. That will tell you definitively whether the data that came from the user is nothing but a numeric entity. -Rasmus -- 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]