Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
Hi, Kris
I have to confirm that that's not really what I wanted.
But many people were now talking about type-hint to scalar, but that was
maybe in another thread in this list :)
To get more to the point what were discussing about want:
Why not always (at least try) to transform the data?
In PHP 5.4 they've introduced quite a lot of new stuff around exactly that:
* Changed silent conversion of array to string to produce a notice.
* Changed silent casting of null/''/false into an Object when adding a
property into a warning.
I would suppose to add a type-hint for the following types:
* Boolean
* integer
* float
* string
Here's the last state what I thought about these type-hints ...
Both of the given examples here should give the same result:
foo(boolean $b, integer $i, float $f, string $s) {
// your code
}
foo2($b, $i, $f, $s) {
$b = (boolean)$b;
$i = (integer)$i;
$f = (float)$f;
$s = (string)$s;
// your code
}
If you view it from that site - you can't get an array to do what you can
do with an object. Therefore I think it's quite OK to break the script
there, but here, as you can transform the values, I'd (at least try to)
transform the given data into the expected format.
The only thing I'm quite unsure about - should we trigger a E_WARNING or
E_NOTICE if we have data-loose in this transformation? Just let it pass as
it's transformable, but trigger some error ...
If you want to get a warning or notice in the function *foo2* then open a
new thread, as I think that should not be discussed here. It affects much
more than just the function-call.
p.s. What about adding another type-hint for resources?
That's something we could check by *is_resource()* and it would make sense
(at least to me).
Bye
Simon
2012/3/2 Kris Craig kris.cr...@gmail.com
I agree with what John said. Limiting the scope to scalars, while having
some advantages, probably wouldn't pass the usefulness test for most
people.
--Kris
On Thu, Mar 1, 2012 at 4:18 PM, John Crenshaw johncrens...@priacta.com
wrote:
From: Richard Lynch [mailto:c...@l-i-e.com]
On Thu, March 1, 2012 2:38 am, John Crenshaw wrote:
You might consider those scripts poor programming practice. We all
do.
But PHP is the language of the unwashed masses, and that was, and
is,
part of why it is hugely popular. Somebody who barely understands
programming can pound away at the keyboard and write a bloody useful
web application, breaking 10,000 Computer Science rules along the
way.
And in 20 minutes I can hack into that application 20 different ways.
This isn't really PHP's fault...or is it? By deliberately catering to
the lowest possible denominator is it possible that PHP itself
contributes to the proliferation of wildly insecure web sites? I do
understand the unwashed masses argument, and yet, the security geek
in me sometimes questions how good this is.
(Before someone flames me, I'm not really saying that we should scrap
any foundational principles or tell basic users to go hang
themselves.
This is mostly philosophical musing.)
We make concerted efforts to educate scripters, by posting the same
thing in all our blogs.
Even if all they understand is Don't do this! it's good enough for
most of them.
Other times the decision was made to just deprecate a feature and
provide a migration path,
if suitable, but spread out over major
releases:
PHP x.0: Feature is bad, but there
PHP x+1.0 Feature is E_DEPRECATED (or documented as such before E_DEP)
[This is the bit
where a LOT of scripted edumacation has to happen.) PHP x+2.0 Feature
is
just gone.
People who completely ignore docs or don't upgrade remain vulnerable,
but there's not much
you can do without making life miserable for a bazillion developers.
No, you've misunderstood. The average new not-really-a-developer has no
concept of security. Every SQL query they write is vulnerable to
injection.
Every echo exposes their site to XSS vulnerabilities. Every form is
vulnerable to CSRF. If they did anything with files in their script I may
be able to read arbitrary files to their server and/or upload and execute
arbitrary scripts. If they used eval() or system() I can probably execute
arbitrary shell code and take control of the entire site. If their server
is badly configured I could capture the entire machine.
This isn't a question of keeping software updated and not using
deprecated
functions, this is a question of discipline that is completely missing
among the unwashed masses as you call them. The intuitive way to handle
many of the most common PHP tasks is also the completely insecure way.
Philosophically, I wonder if we do a great disservice by encouraging
these
people to tinker with code at all. We do so knowing (or at least we
should
know) that anything they create will inevitably be hacked. We fuel the
widespread security
Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
Hi, All
Let me update my last functions as I got an inspiration from Anthony and
his proof-of-concept:
foo( (boolean) $b, (integer) $i, (float) $f, (string) $s) {
// your code
}
foo2($b, $i, $f, $s) {
$b = (boolean)$b;
$i = (integer)$i;
$f = (float)$f;
$s = (string)$s;
// your code
}
Now here a rule I thought could be acceptable to differ between the
type-hint for classes and arrays and this notation:
If the type is wrapped in parentheses, the system will try to convert the
given value. Otherwise it will handle it strict.
Strict is currently only available for classes and arrays, and I don't want
to get more things in this list (excepted by resources, what is the last
what would make sense here).
Dynamic (the one with the parentheses) could then well be something like
boolean, integer, float, string and array. Array is also in this list as I
would like to have an option to give an object in here that implements all
interfaces that makes an object accessible as an array - for example
ArrayIterator.
Bye
Simon
2012/3/2 Simon Schick simonsimc...@googlemail.com
Hi, Kris
I have to confirm that that's not really what I wanted.
But many people were now talking about type-hint to scalar, but that was
maybe in another thread in this list :)
To get more to the point what were discussing about want:
Why not always (at least try) to transform the data?
In PHP 5.4 they've introduced quite a lot of new stuff around exactly that:
* Changed silent conversion of array to string to produce a notice.
* Changed silent casting of null/''/false into an Object when adding a
property into a warning.
I would suppose to add a type-hint for the following types:
* Boolean
* integer
* float
* string
Here's the last state what I thought about these type-hints ...
Both of the given examples here should give the same result:
foo(boolean $b, integer $i, float $f, string $s) {
// your code
}
foo2($b, $i, $f, $s) {
$b = (boolean)$b;
$i = (integer)$i;
$f = (float)$f;
$s = (string)$s;
// your code
}
If you view it from that site - you can't get an array to do what you can
do with an object. Therefore I think it's quite OK to break the script
there, but here, as you can transform the values, I'd (at least try to)
transform the given data into the expected format.
The only thing I'm quite unsure about - should we trigger a E_WARNING or
E_NOTICE if we have data-loose in this transformation? Just let it pass as
it's transformable, but trigger some error ...
If you want to get a warning or notice in the function *foo2* then open a
new thread, as I think that should not be discussed here. It affects much
more than just the function-call.
p.s. What about adding another type-hint for resources?
That's something we could check by *is_resource()* and it would make
sense (at least to me).
Bye
Simon
2012/3/2 Kris Craig kris.cr...@gmail.com
I agree with what John said. Limiting the scope to scalars, while having
some advantages, probably wouldn't pass the usefulness test for most
people.
--Kris
On Thu, Mar 1, 2012 at 4:18 PM, John Crenshaw johncrens...@priacta.com
wrote:
From: Richard Lynch [mailto:c...@l-i-e.com]
On Thu, March 1, 2012 2:38 am, John Crenshaw wrote:
You might consider those scripts poor programming practice. We all
do.
But PHP is the language of the unwashed masses, and that was, and
is,
part of why it is hugely popular. Somebody who barely understands
programming can pound away at the keyboard and write a bloody
useful
web application, breaking 10,000 Computer Science rules along the
way.
And in 20 minutes I can hack into that application 20 different
ways.
This isn't really PHP's fault...or is it? By deliberately catering
to
the lowest possible denominator is it possible that PHP itself
contributes to the proliferation of wildly insecure web sites? I do
understand the unwashed masses argument, and yet, the security
geek
in me sometimes questions how good this is.
(Before someone flames me, I'm not really saying that we should
scrap
any foundational principles or tell basic users to go hang
themselves.
This is mostly philosophical musing.)
We make concerted efforts to educate scripters, by posting the same
thing in all our blogs.
Even if all they understand is Don't do this! it's good enough for
most of them.
Other times the decision was made to just deprecate a feature and
provide a migration path,
if suitable, but spread out over major
releases:
PHP x.0: Feature is bad, but there
PHP x+1.0 Feature is E_DEPRECATED (or documented as such before E_DEP)
[This is the bit
where a LOT of scripted edumacation has to happen.) PHP x+2.0 Feature
is
just gone.
People who completely ignore docs or don't upgrade remain vulnerable,
but there's not much
you can do without making life miserable for a bazillion
Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
On Thu, Mar 1, 2012 at 4:18 PM, John Crenshaw johncrens...@priacta.com wrote: No, you've misunderstood. The average new not-really-a-developer has no concept of security. Every SQL query they write is vulnerable to injection. Every echo exposes their site to XSS vulnerabilities. Every form is vulnerable to CSRF. If they did anything with files in their script I may be able to read arbitrary files to their server and/or upload and execute arbitrary scripts. If they used eval() or system() I can probably execute arbitrary shell code and take control of the entire site. If their server is badly configured I could capture the entire machine. PHP is as vulnerable as you make it, This isn't a question of keeping software updated and not using deprecated functions, this is a question of discipline that is completely missing among the unwashed masses as you call them. The intuitive way to handle many of the most common PHP tasks is also the completely insecure way. Philosophically, I wonder if we do a great disservice by encouraging these people to tinker with code at all. We do so knowing (or at least we should know) that anything they create will inevitably be hacked. We fuel the widespread security problems that currently plague the web. John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
You might consider those scripts poor programming practice. We all do. But PHP is the language of the unwashed masses, and that was, and is, part of why it is hugely popular. Somebody who barely understands programming can pound away at the keyboard and write a bloody useful web application, breaking 10,000 Computer Science rules along the way. And in 20 minutes I can hack into that application 20 different ways. This isn't really PHP's fault...or is it? By deliberately catering to the lowest possible denominator is it possible that PHP itself contributes to the proliferation of wildly insecure web sites? I do understand the unwashed masses argument, and yet, the security geek in me sometimes questions how good this is. (Before someone flames me, I'm not really saying that we should scrap any foundational principles or tell basic users to go hang themselves. This is mostly philosophical musing.) John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
Secure code is not about the instrument, it's about how you write it. Insecure spagetti code can be written in any language.
RE: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
From: Richard Lynch [mailto:c...@l-i-e.com]
On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
I'm beginning to think that the type hinting question is too closely
related to the dirty secrets of type juggling to resolve them
separately. You may have to either discard consistency, or else fix
the problem of silent bizarre conversions at the same time ('foo'==0,
'123abc'=123). Fixing the conversions is a BC break though.
[short version]
One man's fixing is another man's feature :-)
Old hands can now hit delete while I wax philosophical.
The operative word was silent. The actual behavior is fine, but the silence
is unexpected. For example, PHP happily accepts substr('foo', 'bar') with no
complaint at all. From a purely philosophical perspective I think almost
everyone would expect *at least* a strict notice.
On a practical level, we have a major barrier and we'll have to decide how to
handle it. As I see it we could do one of the following:
1. Discard consistency (!!)
2. Try to convince people to make these bizarre conversions not silent (BC
break)
3. Try to find a creative solution to be consistent without changing anything
about the conversion behavior. (I'm not seeing a way to do this one, unless we
redefine consistent.)
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
Hi, John
Just to add an idea to yours ..
Do you think it's a compatibility-break if we'd decide to send a E_NOTICE
or E_WARNING if we f.e. try to give a string to a method that just allows
integer for this argument?
No break at all, just a E_NOTICE or E_WARNING as the script can succeed
anyways.
Bye
Simon
2012/3/1 John Crenshaw johncrens...@priacta.com
From: Richard Lynch [mailto:c...@l-i-e.com]
On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
I'm beginning to think that the type hinting question is too closely
related to the dirty secrets of type juggling to resolve them
separately. You may have to either discard consistency, or else fix
the problem of silent bizarre conversions at the same time ('foo'==0,
'123abc'=123). Fixing the conversions is a BC break though.
[short version]
One man's fixing is another man's feature :-)
Old hands can now hit delete while I wax philosophical.
The operative word was silent. The actual behavior is fine, but the
silence is unexpected. For example, PHP happily accepts substr('foo',
'bar') with no complaint at all. From a purely philosophical perspective I
think almost everyone would expect *at least* a strict notice.
On a practical level, we have a major barrier and we'll have to decide how
to handle it. As I see it we could do one of the following:
1. Discard consistency (!!)
2. Try to convince people to make these bizarre conversions not silent (BC
break)
3. Try to find a creative solution to be consistent without changing
anything about the conversion behavior. (I'm not seeing a way to do this
one, unless we redefine consistent.)
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
From: Simon Schick [mailto:simonsimc...@googlemail.com] Hi, John Just to add an idea to yours .. Do you think it's a compatibility-break if we'd decide to send a E_NOTICE or E_WARNING if we f.e. try to give a string to a method that just allows integer for this argument? No break at all, just a E_NOTICE or E_WARNING as the script can succeed anyways. Bye Simon That's what I was calling inconsistent, specifically because (int)'foo' == 0 with no warning whatsoever, but int $a = 'foo' would be 0 with an error of some sort. Behavior with respect to when an error is raised is inconsistent. In both cases there is a very lossy conversion, why is there an error in one case and not the other? Inconsistent. On the other hand if you add an error in the legacy case now that's a BC break. One might argue that it should always have given a notice, but it didn't, so it's a change, and a BC break. Pick your poison. John Crenshaw Priacta, Inc.
Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
If any of you are interested in such change in PHP, please get
together and write a complete RFC. As I do not see any kind of
progress but, as you stated, some philosophical discussions. That's
all good but after 2 weeks, it is time to move forward (or stop).
Cheers,
On Thu, Mar 1, 2012 at 4:02 AM, Richard Lynch c...@l-i-e.com wrote:
On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
I'm beginning to think that the type hinting question is too closely
related to the dirty secrets of type juggling to resolve them
separately. You may have to either discard consistency, or else fix
the problem of silent bizarre conversions at the same time ('foo'==0,
'123abc'=123). Fixing the conversions is a BC break though.
[short version]
One man's fixing is another man's feature :-)
Old hands can now hit delete while I wax philosophical.
[long version]
PHP does the type juggling because HTTP data is all string. It's a
feature, because PHP's main purpose was to process HTTP input.
[Yes, I know you did not dispute this. It's just foreshadowing...]
Once one accepts the premise that automatic type-juggling is good,
the idea that (int) 123 abc turns into 123 may seem incredibly
wrong or right depending on how useful one has found it.
I have found it useful, and others have as well, to the point that we
don't consider it something to fix but a feature
Obviously, others disagree. And that's okay. We get that some
disagree, and even why some disagree. We've all coded in C, C++, C#,
Forth, Modula 2, Lisp, PL/1, and many more, collectively.
We choose PHP, at times, because it is the way it is, as broken as
it may seem to others. And they are legion. One only needs to review
blogs and mailing lists of fans of other strictly-typed languages to
see this.
But Breaking Compatibility with something so deeply ingrained in the
culture and language, which goes back consistently at least to PHP3,
and probably PHP/FI, is a non-starter.
There are probably literally millions of scripts that will break out
there. That's simply unacceptable, and I trust you understand why
that is so.
You might consider those scripts poor programming practice. We all do.
But PHP is the language of the unwashed masses, and that was, and is,
part of why it is hugely popular. Somebody who barely understands
programming can pound away at the keyboard and write a bloody useful
web application, breaking 10,000 Computer Science rules along the way.
It's duct tape and bailing wire. And we love it for that.
If the app is useful enough, it might even get cleaned up. Or just
more duct tape and bailing wire is applied, more likely. :-)
Even at a major release, PHP has, by and large, strived to remain
Backwards Compatible, unless a VERY compelling reason was presented.
A vocal minority, or even a majority, of developers does not qualify.
That's pretty much why the Core Devs' veto power exists.
Some of the proposals and ideas lately have adhered to that concept of
not breaking Backwards Compatibility. Others have not, and those are
just non-starters.
But PHP core has always had the mantra Keep It Simple, Stupid
If one wants a complex language, PHP is simply not going to be it, and
virtually all of these proposals do not fit the KISS principle, at a
fundamental level of Any idiot can read halfway decent code and
puzzle out what it does in less than a day.
This is a Religious Issue, a personal preference, a philosophical
ideal, etc. Right or wrong, it is what it is, by choice, by the core
developers who have put years worth of effort into it.
Please don't read this as go away or a restatement of the arguments
that have been labeled as circular before. I am merely trying to
explain why PHP is the way it is, at a 10,000 foot level, and why so
many core devs are resistant to the changes being proposed.
I highly respect all the efforts and the alternative philosophical
differences, and even the guiding principles of Computer Science
driving them. PHP is just not the language for Computer Science types,
for the most part. It's for the masses.
Some CS types like it in certain situations, which is all to the good,
or it would be a total mess :-) We embrace its flaws and ugly hacks
because, like it or not, it works for what it's designed to do.
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
That's what I was calling inconsistent, specifically because (int)'foo' == 0 with no warning whatsoever, but int $a = 'foo' would be 0 with an error of some sort. Behavior with respect to when an error is raised is inconsistent. In both cases there is a very lossy conversion, why is there an error in one case and not the other? Inconsistent. +1 However, I would love to have int $a = 'foo' cast to 0 without any error. New functionality without breaking BC. Lazare INEPOLOGLOU Ingénieur Logiciel 2012/3/1 John Crenshaw johncrens...@priacta.com From: Simon Schick [mailto:simonsimc...@googlemail.com] Hi, John Just to add an idea to yours .. Do you think it's a compatibility-break if we'd decide to send a E_NOTICE or E_WARNING if we f.e. try to give a string to a method that just allows integer for this argument? No break at all, just a E_NOTICE or E_WARNING as the script can succeed anyways. Bye Simon That's what I was calling inconsistent, specifically because (int)'foo' == 0 with no warning whatsoever, but int $a = 'foo' would be 0 with an error of some sort. Behavior with respect to when an error is raised is inconsistent. In both cases there is a very lossy conversion, why is there an error in one case and not the other? Inconsistent. On the other hand if you add an error in the legacy case now that's a BC break. One might argue that it should always have given a notice, but it didn't, so it's a change, and a BC break. Pick your poison. John Crenshaw Priacta, Inc.
Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
On Thu, Mar 1, 2012 at 9:52 AM, Simon Schick simonsimc...@googlemail.comwrote:
Hi, John
Just to add an idea to yours ..
Do you think it's a compatibility-break if we'd decide to send a E_NOTICE
or E_WARNING if we f.e. try to give a string to a method that just allows
integer for this argument?
No break at all, just a E_NOTICE or E_WARNING as the script can succeed
anyways.
Perhaps I missed something, but since 5.3, the new parameter parsing API
throws a Warning when types are not strictly honored.
This has been a major feature in favor of cleaner programming.
Try substr('foo', 'bar'), in PHP = 5.3 and you get a warning and the
function returns null.
Julien.P
Bye
Simon
2012/3/1 John Crenshaw johncrens...@priacta.com
From: Richard Lynch [mailto:c...@l-i-e.com]
On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
I'm beginning to think that the type hinting question is too closely
related to the dirty secrets of type juggling to resolve them
separately. You may have to either discard consistency, or else fix
the problem of silent bizarre conversions at the same time ('foo'==0,
'123abc'=123). Fixing the conversions is a BC break though.
[short version]
One man's fixing is another man's feature :-)
Old hands can now hit delete while I wax philosophical.
The operative word was silent. The actual behavior is fine, but the
silence is unexpected. For example, PHP happily accepts substr('foo',
'bar') with no complaint at all. From a purely philosophical perspective
I
think almost everyone would expect *at least* a strict notice.
On a practical level, we have a major barrier and we'll have to decide
how
to handle it. As I see it we could do one of the following:
1. Discard consistency (!!)
2. Try to convince people to make these bizarre conversions not silent
(BC
break)
3. Try to find a creative solution to be consistent without changing
anything about the conversion behavior. (I'm not seeing a way to do this
one, unless we redefine consistent.)
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
From: Richard Lynch [mailto:c...@l-i-e.com]
On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
I'm beginning to think that the type hinting question is too closely
related to the dirty secrets of type juggling to resolve them
separately. You may have to either discard consistency, or else fix
the problem of silent bizarre conversions at the same time ('foo'==0,
'123abc'=123). Fixing the conversions is a BC break though.
[short version]
One man's fixing is another man's feature :-)
Old hands can now hit delete while I wax philosophical.
The operative word was silent. The actual behavior is fine, but the
silence is unexpected. For example, PHP happily accepts substr('foo',
'bar') with no complaint at all. From a purely philosophical perspective I
think almost everyone would expect *at least* a strict notice.
On a practical level, we have a major barrier and we'll have to decide how
to handle it. As I see it we could do one of the following:
1. Discard consistency (!!)
2. Try to convince people to make these bizarre conversions not silent (BC
break)
3. Try to find a creative solution to be consistent without changing
anything about the conversion behavior. (I'm not seeing a way to do this
one, unless we redefine consistent.)
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, Mar 1, 2012 at 9:52 AM, Simon Schick simonsimc...@googlemail.com
wrote:
Hi, John
Just to add an idea to yours ..
Do you think it's a compatibility-break if we'd decide to send a E_NOTICE
or E_WARNING if we f.e. try to give a string to a method that just allows
integer for this argument?
No break at all, just a E_NOTICE or E_WARNING as the script can succeed
anyways.
Perhaps I missed something, but since 5.3, the new parameter parsing API
throws a Warning when types are not strictly honored.
This has been a major feature in favor of cleaner programming.
Try substr('foo', 'bar'), in PHP = 5.3 and you get a warning and the
function returns null.
Julien.P
Bye
Simon
Ah, didn't notice the *new* behavior. That simplifies things substantially.
I also had another realization today, which is that there's already strong
precedent for treating parameter hints more aggressively than a type cast. For
example, you can cast between arrays and objects, with no errors, but the type
hints will still generate errors. I think this settles the consistency issue
for me.
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
On Thu, March 1, 2012 2:38 am, John Crenshaw wrote: You might consider those scripts poor programming practice. We all do. But PHP is the language of the unwashed masses, and that was, and is, part of why it is hugely popular. Somebody who barely understands programming can pound away at the keyboard and write a bloody useful web application, breaking 10,000 Computer Science rules along the way. And in 20 minutes I can hack into that application 20 different ways. This isn't really PHP's fault...or is it? By deliberately catering to the lowest possible denominator is it possible that PHP itself contributes to the proliferation of wildly insecure web sites? I do understand the unwashed masses argument, and yet, the security geek in me sometimes questions how good this is. (Before someone flames me, I'm not really saying that we should scrap any foundational principles or tell basic users to go hang themselves. This is mostly philosophical musing.) We make concerted efforts to educate scripters, by posting the same thing in all our blogs. Even if all they understand is Don't do this! it's good enough for most of them. Other times the decision was made to just deprecate a feature and provide a migration path, if suitable, but spread out over major releases: PHP x.0: Feature is bad, but there PHP x+1.0 Feature is E_DEPRECATED (or documented as such before E_DEP) [This is the bit where a LOT of scripted edumacation has to happen.) PHP x+2.0 Feature is just gone. People who completely ignore docs or don't upgrade remain vulnerable, but there's not much you can do without making life miserable for a bazillion developers. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
Hi, John
Therefore I think it would be easy to explain how a type-hint for scalar
could work.
You can explain it as saying that the following two functions should be end
up in exactly the same result, whatever you're pasting into:
function foo_one(scalar $bar) {}
function foo_two($bar) {
if (!is_scalar($bar))
trigger_error(Catchable fatal error: Argument ? passed to ? must be a
scalar, ? given,, E_RECOVERABLE_ERROR);
}
The error-message is just an example - but that would keep the three
type-hint possibilities in one and the same functionality - like just
allowing exactly this type.
You cannot even pass a class that extends* ArrayIterator *into a property
that requires an array. So I think we should also here (at least for
scalar) do a really strict thing.
Bye
Simon
2012/3/1 John Crenshaw johncrens...@priacta.com
From: Richard Lynch [mailto:c...@l-i-e.com]
On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
I'm beginning to think that the type hinting question is too
closely
related to the dirty secrets of type juggling to resolve them
separately. You may have to either discard consistency, or else fix
the problem of silent bizarre conversions at the same time
('foo'==0,
'123abc'=123). Fixing the conversions is a BC break though.
[short version]
One man's fixing is another man's feature :-)
Old hands can now hit delete while I wax philosophical.
The operative word was silent. The actual behavior is fine, but the
silence is unexpected. For example, PHP happily accepts substr('foo',
'bar') with no complaint at all. From a purely philosophical
perspective I
think almost everyone would expect *at least* a strict notice.
On a practical level, we have a major barrier and we'll have to decide
how
to handle it. As I see it we could do one of the following:
1. Discard consistency (!!)
2. Try to convince people to make these bizarre conversions not silent
(BC
break)
3. Try to find a creative solution to be consistent without changing
anything about the conversion behavior. (I'm not seeing a way to do
this
one, unless we redefine consistent.)
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, Mar 1, 2012 at 9:52 AM, Simon Schick
simonsimc...@googlemail.com wrote:
Hi, John
Just to add an idea to yours ..
Do you think it's a compatibility-break if we'd decide to send a E_NOTICE
or E_WARNING if we f.e. try to give a string to a method that just allows
integer for this argument?
No break at all, just a E_NOTICE or E_WARNING as the script can succeed
anyways.
Perhaps I missed something, but since 5.3, the new parameter parsing API
throws a Warning when types are not strictly honored.
This has been a major feature in favor of cleaner programming.
Try substr('foo', 'bar'), in PHP = 5.3 and you get a warning and the
function returns null.
Julien.P
Bye
Simon
Ah, didn't notice the *new* behavior. That simplifies things substantially.
I also had another realization today, which is that there's already strong
precedent for treating parameter hints more aggressively than a type cast.
For example, you can cast between arrays and objects, with no errors, but
the type hints will still generate errors. I think this settles the
consistency issue for me.
John Crenshaw
Priacta, Inc.
RE: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
From: Simon Schick [mailto:simonsimc...@googlemail.com]
Hi, John
Therefore I think it would be easy to explain how a type-hint for scalar
could work.
You can explain it as saying that the following two functions should be end
up in exactly the same result, whatever you're pasting into:
function foo_one(scalar $bar) {}
function foo_two($bar) {
if (!is_scalar($bar))
trigger_error(Catchable fatal error: Argument ? passed to ? must be a
scalar, ? given,, E_RECOVERABLE_ERROR);
}
Type hints that only ensure that something is a scalar are a non-starter for
me. I'm not going to waste my time on something like that. You're not going to
get any better core support with this, and you'll alienate support from a
majority of userland as well. The average function doesn't need just a scalar,
but any scalar will do. Most functions need something specific, like a string,
or a number. sqrt('foo') doesn't make any sense, it needs a number, not just a
scalar.
John Crenshaw
Priacta, Inc.
RE: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
From: Richard Lynch [mailto:c...@l-i-e.com] On Thu, March 1, 2012 2:38 am, John Crenshaw wrote: You might consider those scripts poor programming practice. We all do. But PHP is the language of the unwashed masses, and that was, and is, part of why it is hugely popular. Somebody who barely understands programming can pound away at the keyboard and write a bloody useful web application, breaking 10,000 Computer Science rules along the way. And in 20 minutes I can hack into that application 20 different ways. This isn't really PHP's fault...or is it? By deliberately catering to the lowest possible denominator is it possible that PHP itself contributes to the proliferation of wildly insecure web sites? I do understand the unwashed masses argument, and yet, the security geek in me sometimes questions how good this is. (Before someone flames me, I'm not really saying that we should scrap any foundational principles or tell basic users to go hang themselves. This is mostly philosophical musing.) We make concerted efforts to educate scripters, by posting the same thing in all our blogs. Even if all they understand is Don't do this! it's good enough for most of them. Other times the decision was made to just deprecate a feature and provide a migration path, if suitable, but spread out over major releases: PHP x.0: Feature is bad, but there PHP x+1.0 Feature is E_DEPRECATED (or documented as such before E_DEP) [This is the bit where a LOT of scripted edumacation has to happen.) PHP x+2.0 Feature is just gone. People who completely ignore docs or don't upgrade remain vulnerable, but there's not much you can do without making life miserable for a bazillion developers. No, you've misunderstood. The average new not-really-a-developer has no concept of security. Every SQL query they write is vulnerable to injection. Every echo exposes their site to XSS vulnerabilities. Every form is vulnerable to CSRF. If they did anything with files in their script I may be able to read arbitrary files to their server and/or upload and execute arbitrary scripts. If they used eval() or system() I can probably execute arbitrary shell code and take control of the entire site. If their server is badly configured I could capture the entire machine. This isn't a question of keeping software updated and not using deprecated functions, this is a question of discipline that is completely missing among the unwashed masses as you call them. The intuitive way to handle many of the most common PHP tasks is also the completely insecure way. Philosophically, I wonder if we do a great disservice by encouraging these people to tinker with code at all. We do so knowing (or at least we should know) that anything they create will inevitably be hacked. We fuel the widespread security problems that currently plague the web. John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
I agree with what John said. Limiting the scope to scalars, while having some advantages, probably wouldn't pass the usefulness test for most people. --Kris On Thu, Mar 1, 2012 at 4:18 PM, John Crenshaw johncrens...@priacta.comwrote: From: Richard Lynch [mailto:c...@l-i-e.com] On Thu, March 1, 2012 2:38 am, John Crenshaw wrote: You might consider those scripts poor programming practice. We all do. But PHP is the language of the unwashed masses, and that was, and is, part of why it is hugely popular. Somebody who barely understands programming can pound away at the keyboard and write a bloody useful web application, breaking 10,000 Computer Science rules along the way. And in 20 minutes I can hack into that application 20 different ways. This isn't really PHP's fault...or is it? By deliberately catering to the lowest possible denominator is it possible that PHP itself contributes to the proliferation of wildly insecure web sites? I do understand the unwashed masses argument, and yet, the security geek in me sometimes questions how good this is. (Before someone flames me, I'm not really saying that we should scrap any foundational principles or tell basic users to go hang themselves. This is mostly philosophical musing.) We make concerted efforts to educate scripters, by posting the same thing in all our blogs. Even if all they understand is Don't do this! it's good enough for most of them. Other times the decision was made to just deprecate a feature and provide a migration path, if suitable, but spread out over major releases: PHP x.0: Feature is bad, but there PHP x+1.0 Feature is E_DEPRECATED (or documented as such before E_DEP) [This is the bit where a LOT of scripted edumacation has to happen.) PHP x+2.0 Feature is just gone. People who completely ignore docs or don't upgrade remain vulnerable, but there's not much you can do without making life miserable for a bazillion developers. No, you've misunderstood. The average new not-really-a-developer has no concept of security. Every SQL query they write is vulnerable to injection. Every echo exposes their site to XSS vulnerabilities. Every form is vulnerable to CSRF. If they did anything with files in their script I may be able to read arbitrary files to their server and/or upload and execute arbitrary scripts. If they used eval() or system() I can probably execute arbitrary shell code and take control of the entire site. If their server is badly configured I could capture the entire machine. This isn't a question of keeping software updated and not using deprecated functions, this is a question of discipline that is completely missing among the unwashed masses as you call them. The intuitive way to handle many of the most common PHP tasks is also the completely insecure way. Philosophically, I wonder if we do a great disservice by encouraging these people to tinker with code at all. We do so knowing (or at least we should know) that anything they create will inevitably be hacked. We fuel the widespread security problems that currently plague the web. John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
I'm beginning to think that the type hinting question is too closely
related to the dirty secrets of type juggling to resolve them
separately. You may have to either discard consistency, or else fix
the problem of silent bizarre conversions at the same time ('foo'==0,
'123abc'=123). Fixing the conversions is a BC break though.
[short version]
One man's fixing is another man's feature :-)
Old hands can now hit delete while I wax philosophical.
[long version]
PHP does the type juggling because HTTP data is all string. It's a
feature, because PHP's main purpose was to process HTTP input.
[Yes, I know you did not dispute this. It's just foreshadowing...]
Once one accepts the premise that automatic type-juggling is good,
the idea that (int) 123 abc turns into 123 may seem incredibly
wrong or right depending on how useful one has found it.
I have found it useful, and others have as well, to the point that we
don't consider it something to fix but a feature
Obviously, others disagree. And that's okay. We get that some
disagree, and even why some disagree. We've all coded in C, C++, C#,
Forth, Modula 2, Lisp, PL/1, and many more, collectively.
We choose PHP, at times, because it is the way it is, as broken as
it may seem to others. And they are legion. One only needs to review
blogs and mailing lists of fans of other strictly-typed languages to
see this.
But Breaking Compatibility with something so deeply ingrained in the
culture and language, which goes back consistently at least to PHP3,
and probably PHP/FI, is a non-starter.
There are probably literally millions of scripts that will break out
there. That's simply unacceptable, and I trust you understand why
that is so.
You might consider those scripts poor programming practice. We all do.
But PHP is the language of the unwashed masses, and that was, and is,
part of why it is hugely popular. Somebody who barely understands
programming can pound away at the keyboard and write a bloody useful
web application, breaking 10,000 Computer Science rules along the way.
It's duct tape and bailing wire. And we love it for that.
If the app is useful enough, it might even get cleaned up. Or just
more duct tape and bailing wire is applied, more likely. :-)
Even at a major release, PHP has, by and large, strived to remain
Backwards Compatible, unless a VERY compelling reason was presented.
A vocal minority, or even a majority, of developers does not qualify.
That's pretty much why the Core Devs' veto power exists.
Some of the proposals and ideas lately have adhered to that concept of
not breaking Backwards Compatibility. Others have not, and those are
just non-starters.
But PHP core has always had the mantra Keep It Simple, Stupid
If one wants a complex language, PHP is simply not going to be it, and
virtually all of these proposals do not fit the KISS principle, at a
fundamental level of Any idiot can read halfway decent code and
puzzle out what it does in less than a day.
This is a Religious Issue, a personal preference, a philosophical
ideal, etc. Right or wrong, it is what it is, by choice, by the core
developers who have put years worth of effort into it.
Please don't read this as go away or a restatement of the arguments
that have been labeled as circular before. I am merely trying to
explain why PHP is the way it is, at a 10,000 foot level, and why so
many core devs are resistant to the changes being proposed.
I highly respect all the efforts and the alternative philosophical
differences, and even the guiding principles of Computer Science
driving them. PHP is just not the language for Computer Science types,
for the most part. It's for the masses.
Some CS types like it in certain situations, which is all to the good,
or it would be a total mess :-) We embrace its flaws and ugly hacks
because, like it or not, it works for what it's designed to do.
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
I agree with your well-thought-out remarks overall. However (and you knew
a however was coming lol), by making these types optional, we would be
allowing full backwards-compatibility without alienating non-CS developers,
since they would be able to continue writing the same code they do now.
Likewise, and I know I keep going back to this, PHP 5's stronger
implementation of OO did not break backwards compatibility or scare away
procedural developers who are not versed on OO concepts. I would cite that
as precedent for this; in that, if done correctly and with great care, this
can be implemented without trampling on PHP's KISS principles IMHO.
--Kris
On Wed, Feb 29, 2012 at 7:02 PM, Richard Lynch c...@l-i-e.com wrote:
On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
I'm beginning to think that the type hinting question is too closely
related to the dirty secrets of type juggling to resolve them
separately. You may have to either discard consistency, or else fix
the problem of silent bizarre conversions at the same time ('foo'==0,
'123abc'=123). Fixing the conversions is a BC break though.
[short version]
One man's fixing is another man's feature :-)
Old hands can now hit delete while I wax philosophical.
[long version]
PHP does the type juggling because HTTP data is all string. It's a
feature, because PHP's main purpose was to process HTTP input.
[Yes, I know you did not dispute this. It's just foreshadowing...]
Once one accepts the premise that automatic type-juggling is good,
the idea that (int) 123 abc turns into 123 may seem incredibly
wrong or right depending on how useful one has found it.
I have found it useful, and others have as well, to the point that we
don't consider it something to fix but a feature
Obviously, others disagree. And that's okay. We get that some
disagree, and even why some disagree. We've all coded in C, C++, C#,
Forth, Modula 2, Lisp, PL/1, and many more, collectively.
We choose PHP, at times, because it is the way it is, as broken as
it may seem to others. And they are legion. One only needs to review
blogs and mailing lists of fans of other strictly-typed languages to
see this.
But Breaking Compatibility with something so deeply ingrained in the
culture and language, which goes back consistently at least to PHP3,
and probably PHP/FI, is a non-starter.
There are probably literally millions of scripts that will break out
there. That's simply unacceptable, and I trust you understand why
that is so.
You might consider those scripts poor programming practice. We all do.
But PHP is the language of the unwashed masses, and that was, and is,
part of why it is hugely popular. Somebody who barely understands
programming can pound away at the keyboard and write a bloody useful
web application, breaking 10,000 Computer Science rules along the way.
It's duct tape and bailing wire. And we love it for that.
If the app is useful enough, it might even get cleaned up. Or just
more duct tape and bailing wire is applied, more likely. :-)
Even at a major release, PHP has, by and large, strived to remain
Backwards Compatible, unless a VERY compelling reason was presented.
A vocal minority, or even a majority, of developers does not qualify.
That's pretty much why the Core Devs' veto power exists.
Some of the proposals and ideas lately have adhered to that concept of
not breaking Backwards Compatibility. Others have not, and those are
just non-starters.
But PHP core has always had the mantra Keep It Simple, Stupid
If one wants a complex language, PHP is simply not going to be it, and
virtually all of these proposals do not fit the KISS principle, at a
fundamental level of Any idiot can read halfway decent code and
puzzle out what it does in less than a day.
This is a Religious Issue, a personal preference, a philosophical
ideal, etc. Right or wrong, it is what it is, by choice, by the core
developers who have put years worth of effort into it.
Please don't read this as go away or a restatement of the arguments
that have been labeled as circular before. I am merely trying to
explain why PHP is the way it is, at a 10,000 foot level, and why so
many core devs are resistant to the changes being proposed.
I highly respect all the efforts and the alternative philosophical
differences, and even the guiding principles of Computer Science
driving them. PHP is just not the language for Computer Science types,
for the most part. It's for the masses.
Some CS types like it in certain situations, which is all to the good,
or it would be a total mess :-) We embrace its flaws and ugly hacks
because, like it or not, it works for what it's designed to do.
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
