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
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,