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 input type=integer or input type=float. All you have is input
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 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...
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 input type=integer or input type=float. All you have is input 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. 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]
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 input type=integer or input type=float. All you have is input
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...
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. It's just
good design to have redundant constraints to achieve high reliability
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: 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...
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]
