Slashdot Mirror
Domain: php.net
Stories and comments across the archive that link to php.net.
Comments · 1,658
-
Re:7 is far less of a fustercluck than 5.2-5.3
Well, threads aren't really that important in the PHP context. Keep in mind, most PHP applications are run via CGI or similar, so they are stateless from a request point of view - at each request the whole application is bootstrapped, run and then exits.The notion that you could fire a tread to do some heavy lifting while the rest of the application executes is, well, naive - the application only exits when all work is done. Also, in some languages (e.g. Java) there is no guarantee that threads will execute on a separate processor, so its not obvious threading will translate directly into performance gains. But hey, let me just point out that PHP actually has pthread support - http://php.net/manual/en/book...., so if anyone wants them, they can use them.
Like every language, PHP has its shortcomings. Some of them are quite ugly (I do identify with most of the issues pointed by "Fractal of Bad Design", and also think the rebuttal is somewhat hilarious), but what productive language doesn't require you to know more than 100 pages? Good programmers will write good code, regardless of the syntax. And its not a general purpose language - at all. Even in web development, there are a lot of situations where PHP is a poor choice. There are also a lot of situations where it is an acceptable choice, regardless of the flaws. Complaining about mysql_* when PDO and prepared statements exist for more than 10 years is also quite amateurish. Every language allows you to shoot yourself in the foot. Granted, PHP does give you a lot of options in this regard, but hey - you can shoot yourself in the foot with C, Java, Assembly, Perl, Python, Erlang or whatever is your poison. Every language has a niche, and failing to understand that is, well, dumb. And in the end it's all ones and zeros being executed in a processor. -
Re:Who cares?..
-
Where?
All I see is release candidates. Is softpedia jumping the gun for page views?
-
PHP.net says Perl & C in 1994. Text::Template,
PHP.net says "1994 - Started writing CGI scripts in C and Perl".
http://talks.php.net/show/comm...By the time PHP was gaining popularity, Text::Template and HTML::Embperl were available for Perl.
Rasmus's comments in this interview are revealing:
"I donâ(TM)t know how to stop it, there was never any intent to write a programming language [â¦] I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the
way."
MP3 recording of these comments:
http://web.archive.org/web/201... -
Re:Everyone has to learn about it.
What's wrong with prepared statements?
http://php.net/manual/en/pdo.p...That last time I touched PHP, over 10 years ago, you could do this.
But then there was crap like this: http://php.net/manual/en/funct... Perhaps they planned to make a mysql_fake_escape_string function but instead accidentally called it mysql_escape_string
-
Re:Everyone has to learn about it.
What's wrong with prepared statements?
http://php.net/manual/en/pdo.p...That last time I touched PHP, over 10 years ago, you could do this.
But then there was crap like this: http://php.net/manual/en/funct... Perhaps they planned to make a mysql_fake_escape_string function but instead accidentally called it mysql_escape_string
-
PHP
In PHP, simply run something like the following against the file and see if you get a valid result back
http://php.net/manual/en/funct...
http://php.net/manual/en/funct... -
PHP
In PHP, simply run something like the following against the file and see if you get a valid result back
http://php.net/manual/en/funct...
http://php.net/manual/en/funct... -
Re:Is it really a waste of time?
We could say ">", "GT" or "gt", or perhaps even "greater than."
I disagree. I believe > is easier to parse while reading code since it separates it from identifiers, control statements, constants, numbers, and other keywords. It's the same reason && is better than "AND" in C syntax derivatives.
I'd be quite pleased with a language that understood all three to be the same thing, with similar broad expression capabilities for everything else as well.
Please, no. Syntactic sugar is one thing but creating multiple equivalent ways to express the same thing is just a readability, support, and maintenance nightmare.
explicit and English-like for the newcomer.
Which is how we got COBOL. It turned out that just making source code use lots (and lots) of English words isn't enough to allow laymen to understand it or make changes, so all you end up with is a language that programmers find exhausting to read and annoying to write.
-
Re:Cookie self declares path
The path and domain are not authenticated to make sure site A does not set a cookie fraudulently for site B.
These are called "third-party cookies", and browsers (for example, Firefox) already have knobs to disable them. That's not the real issue here, however.
Another problem seems to be, the browsers present all the values associated with the name to the web site, even the cookies not set by that site.
Not only that, a site could get cookies set by "parent" and "child" sites. Furthermore, a lot of web-programming languages (including PHP, ASP.NET, Classic ASP, and GWT) expose the cookies as a key-value store where the key is simply the name of the cookie, and don't document which cookie they use if the browser sends multiple ones with the same key. (Java is a bit better, it just exposes a bucket, but that's harder to work with.)
-
Re:Quite a version jump
If you want to know why PHP skipped 6, this is an interesting read: https://wiki.php.net/rfc/php6
But the key reason seems to be (selective c&p from the page):
- PHP 6 already existed and it was something completely different.
- PHP 6, the original PHP 6, has been discussed in detail in many PHP conferences.
- PHP 6 was widely known not only within the Internals community, but around the PHP community at large.
- There's lots of PHP 6 information, about the original PHP 6, that exists around the web. Books are the smallest part of the problem. -
Type 4 UUIDs
The combination of time (the UUID can be time boxed), activity (a successful login nullifies the UUID), and possession (control of the account's registered email address)
My concern is how to keep someone between your server and the subscriber's MUA from compromising "possession", or how to establish "possession" the first time.
Assuming the coders didn't decide to come up with their own GUID generation algorithm that is easily reverse engineered and seeded
I just use a PRNG. If I need it as a GUID, I request 120 random bits and format them as a type 4 UUID. Is that good enough?
-
Re:PHP is great
Don't even get me started on mysql_escape_string [php.net] vs. mysql_real_escape_string [php.net]
If you see anyone using the mysql extension then they deserve to receive as much shit as you can give them. It was outdated in 2004. People should be using PDO these days.
-
Re:Use ===
Yup, Javascript's == operator is just as fucked up.
* http://strilanc.com/visualizat...
> PHP developers would be wise to read that to see what warts PHP shares with some other popular languages.
You and I wish that but sadly that will never happen based on their past apologists. Too much ego and stupidity at stake such as having a broken ternary operator ?: as opposed to C. (WTF!?) And then you get stupid bugs like this memory leak
This post sums up the problem with the design of PHP:
http://www.reddit.com/r/lolphp...
The only way to "fix" PHP is to throw it in garbage can where it belongs and start over.
-
Re: PHP is great
Standards change all the time.
Such as Python 2 to Python 3.
Error handling. Look it up. Or, rather, the designers need to do that and then implement something sane, and do it consistently.
"Sane" would involve dropping "warnings" in favor of exceptions. Fortunately, PHP's error handling allows your program to do this most of the way, using ErrorException:
function exception_error_handler($severity, $message, $file, $line) {
if (error_reporting() & $severity) {
throw new ErrorException($message, 0, $severity, $file, $line);
}
}
set_error_handler("exception_error_handler");My beef with PHP error handling is that certain errors are fatal in PHP that are catchable in Python, such as a syntax error in include_once or a call to an undefined function.
-
Re:A poor workman...
I'll probably be downmodded but I'm going to call horseshit on that cliche. While it may be PC to be in denial over crappy tools, the fact remains some tools (programming languages) are well designed and others are not. So yeah, um, no, I don't buy that argument that a poor craftsman blames his tools. It is the good craftsman that is able to spot the crap tools DUE to experience of having used good ones AND crap ones that they can tell what is complete shit.
Second, just because you CAN write code in Brainfuck doesn't mean you _should_; It is _still_ a crappy language for programming. PHP is no different. It was designed (LOL! Ya, right) and implemented by someone who didn't have a fucking clue what they were doing.
The problem with a shite language like PHP is two-fold:
1. The language is inconsistent with too many hidden gotcha's. The == operator is broken that, seriously, you can't make have this dumb shit up. When the official docs has a page called Inconsistent Behaviours you know there is a bigger problem
2. The quality of programmers tends to be extremely poor because they are too busying being apologists for their PHucked uP language.
We have a name for people who like suffering: Masochists.
Meanwhile, the rest of us are laughing our asses of at their self-induced suffer over their choice of stupid tools.
-
Re:PHP is great
Indeed. PHP is one of the shittiest languages ever implemented.
* https://wiki.php.net/rfc/incon...
It tends to bring out all the language apologists who are in denial over how shite it is:
* http://www.reddit.com/r/lolphp...
It makes crappy Javascript look good in comparison:
-
Re:PHP is great
PHP is a truly terrible language, with a truly terrible API. Just look at functions like implode, which can accept parameters in either order. Also (according to one commenter), imploding an array of booleans results in the "true" values being converted to 1, and the "false" values being converted to empty string. That's just a single function. Don't even get me started on mysql_escape_string vs. mysql_real_escape_string
The only reason it's so popular is that for such a long time it was the only choice for server side languages on a shared hosting environment. Even now there aren't really any good alternatives. Shared hosts still don't allow things like Java,.Net, or Node.JS on the server side unless you are prepared to pay a premium. Many hosts don't even offer Ruby, or Python, even though they don't require a constantly running process.
PHP started off as a toy project, and although a lot of work has been done to add functionality to make it useful, it still shows that it was lacking a lot of design considerations. Object Oriented capabilities and namespaces were tacked on later, and it really does feel tacked on, because only a very small part of the available libraries use object oriented features.
-
Re:PHP is great
PHP is a truly terrible language, with a truly terrible API. Just look at functions like implode, which can accept parameters in either order. Also (according to one commenter), imploding an array of booleans results in the "true" values being converted to 1, and the "false" values being converted to empty string. That's just a single function. Don't even get me started on mysql_escape_string vs. mysql_real_escape_string
The only reason it's so popular is that for such a long time it was the only choice for server side languages on a shared hosting environment. Even now there aren't really any good alternatives. Shared hosts still don't allow things like Java,.Net, or Node.JS on the server side unless you are prepared to pay a premium. Many hosts don't even offer Ruby, or Python, even though they don't require a constantly running process.
PHP started off as a toy project, and although a lot of work has been done to add functionality to make it useful, it still shows that it was lacking a lot of design considerations. Object Oriented capabilities and namespaces were tacked on later, and it really does feel tacked on, because only a very small part of the available libraries use object oriented features.
-
Re:PHP is great
PHP is a truly terrible language, with a truly terrible API. Just look at functions like implode, which can accept parameters in either order. Also (according to one commenter), imploding an array of booleans results in the "true" values being converted to 1, and the "false" values being converted to empty string. That's just a single function. Don't even get me started on mysql_escape_string vs. mysql_real_escape_string
The only reason it's so popular is that for such a long time it was the only choice for server side languages on a shared hosting environment. Even now there aren't really any good alternatives. Shared hosts still don't allow things like Java,.Net, or Node.JS on the server side unless you are prepared to pay a premium. Many hosts don't even offer Ruby, or Python, even though they don't require a constantly running process.
PHP started off as a toy project, and although a lot of work has been done to add functionality to make it useful, it still shows that it was lacking a lot of design considerations. Object Oriented capabilities and namespaces were tacked on later, and it really does feel tacked on, because only a very small part of the available libraries use object oriented features.
-
Re:PHP is fine
Only a fanboy makes excuses for why they are too blind to see the many ways it is broken. PHP was designed and developed by a complete fucktard. Let's look at some code
php -a
echo true . "\n";
echo false . "\n";
echo TRUE . "\n";
echo FALSE . "\n";Note: The online manual is completely useless:
* true http://php.net/manual-lookup.p...
* false http://php.net/manual-lookup.p...
* TRUE http://php.net/manual-lookup.p...
* FALSE http://php.net/manual-lookup.p...
More stupid shit PHP does
if( 1 == "1" ) echo "ok!\n";
if( 0 == "0" ) echo "ok!\n";
if( "0" ) echo "nope\n";
if( "00" ) echo "wat\n";
if( "-0" ) echo "wat\n";
if( "0.0" ) echo "wat\n";
if( 0 == "" ) echo "wat\n";
if( 0 == " " ) echo "wat\n";
if( 0 == " wat" ) echo "wat\n";
if( 0 == "\t" ) echo "wat\n";
if( 0 == "\r" ) echo "wat\n";
if( 0 == "\n" ) echo "wat\n";In what bizarro universe would this stupid shit make _any_ sense??
PHP is just as bad as Javascript's == operator. If you are just going to force people to use === for type safety, then _maybe_ you just rethink what the equality operator is _supposed_ to do.
-
Re:PHP is fine
Only a fanboy makes excuses for why they are too blind to see the many ways it is broken. PHP was designed and developed by a complete fucktard. Let's look at some code
php -a
echo true . "\n";
echo false . "\n";
echo TRUE . "\n";
echo FALSE . "\n";Note: The online manual is completely useless:
* true http://php.net/manual-lookup.p...
* false http://php.net/manual-lookup.p...
* TRUE http://php.net/manual-lookup.p...
* FALSE http://php.net/manual-lookup.p...
More stupid shit PHP does
if( 1 == "1" ) echo "ok!\n";
if( 0 == "0" ) echo "ok!\n";
if( "0" ) echo "nope\n";
if( "00" ) echo "wat\n";
if( "-0" ) echo "wat\n";
if( "0.0" ) echo "wat\n";
if( 0 == "" ) echo "wat\n";
if( 0 == " " ) echo "wat\n";
if( 0 == " wat" ) echo "wat\n";
if( 0 == "\t" ) echo "wat\n";
if( 0 == "\r" ) echo "wat\n";
if( 0 == "\n" ) echo "wat\n";In what bizarro universe would this stupid shit make _any_ sense??
PHP is just as bad as Javascript's == operator. If you are just going to force people to use === for type safety, then _maybe_ you just rethink what the equality operator is _supposed_ to do.
-
Re:PHP is fine
Only a fanboy makes excuses for why they are too blind to see the many ways it is broken. PHP was designed and developed by a complete fucktard. Let's look at some code
php -a
echo true . "\n";
echo false . "\n";
echo TRUE . "\n";
echo FALSE . "\n";Note: The online manual is completely useless:
* true http://php.net/manual-lookup.p...
* false http://php.net/manual-lookup.p...
* TRUE http://php.net/manual-lookup.p...
* FALSE http://php.net/manual-lookup.p...
More stupid shit PHP does
if( 1 == "1" ) echo "ok!\n";
if( 0 == "0" ) echo "ok!\n";
if( "0" ) echo "nope\n";
if( "00" ) echo "wat\n";
if( "-0" ) echo "wat\n";
if( "0.0" ) echo "wat\n";
if( 0 == "" ) echo "wat\n";
if( 0 == " " ) echo "wat\n";
if( 0 == " wat" ) echo "wat\n";
if( 0 == "\t" ) echo "wat\n";
if( 0 == "\r" ) echo "wat\n";
if( 0 == "\n" ) echo "wat\n";In what bizarro universe would this stupid shit make _any_ sense??
PHP is just as bad as Javascript's == operator. If you are just going to force people to use === for type safety, then _maybe_ you just rethink what the equality operator is _supposed_ to do.
-
Re:PHP is fine
Only a fanboy makes excuses for why they are too blind to see the many ways it is broken. PHP was designed and developed by a complete fucktard. Let's look at some code
php -a
echo true . "\n";
echo false . "\n";
echo TRUE . "\n";
echo FALSE . "\n";Note: The online manual is completely useless:
* true http://php.net/manual-lookup.p...
* false http://php.net/manual-lookup.p...
* TRUE http://php.net/manual-lookup.p...
* FALSE http://php.net/manual-lookup.p...
More stupid shit PHP does
if( 1 == "1" ) echo "ok!\n";
if( 0 == "0" ) echo "ok!\n";
if( "0" ) echo "nope\n";
if( "00" ) echo "wat\n";
if( "-0" ) echo "wat\n";
if( "0.0" ) echo "wat\n";
if( 0 == "" ) echo "wat\n";
if( 0 == " " ) echo "wat\n";
if( 0 == " wat" ) echo "wat\n";
if( 0 == "\t" ) echo "wat\n";
if( 0 == "\r" ) echo "wat\n";
if( 0 == "\n" ) echo "wat\n";In what bizarro universe would this stupid shit make _any_ sense??
PHP is just as bad as Javascript's == operator. If you are just going to force people to use === for type safety, then _maybe_ you just rethink what the equality operator is _supposed_ to do.
-
Re:That's WordPress in a nutshell
You can't run a serious website on Wordpress AND use a cheap host. Cheap hosts do not install the necessary opcode caches that are required to make the site not run slow and load-spike the server (Dreamhost will just nuke your site if it overloads... because they don't install any php opcode cache.)
That's not necessarily true (depending on how you define "cheap" hosting services). You may have to shop around a bit, but I've found that most commodity hosting services support at least Zend opcache, or they can support php 5.5, which includes opcache out of the box.
-
Re:Uh, okay.
PHP is a carcass...
That is a wild exaggeration. Though personally I would like it to just die, the most you can say at the moment is that its exponential growth phase is over, and thus is rapidly losing share to other platforms that are still growing exponentially. It served its purpose and continues to carry much of the workload on the web but its glory days are over. Thankfully.
-
Re: Not the same use cases
Just want to point out there is also the pthreads extension (through PECL). See http://pecl.php.net/package/pt... and http://php.net/manual/en/book....
I'm currently building a proof of concept instant messaging platform (server and client) with php, pthreads, and sockets.
I could write it in node.js, but I really like the C-likeness of PHP.
-
Re: Not the same use cases
Just want to point out there is also the pthreads extension (through PECL). See http://pecl.php.net/package/pt... and http://php.net/manual/en/book....
I'm currently building a proof of concept instant messaging platform (server and client) with php, pthreads, and sockets.
I could write it in node.js, but I really like the C-likeness of PHP.
-
Re:Why the distros?
"well, distributions backport security fixes, so 5.3.3 is secure on distro XYZ".
Are you aware of any analysis as to the extent that is actually true, ie for distro X or Y which patches really have been backported and which are skipped?
I had a quick poke about the W3Tech site and couldn't really see much of their methodology, especially in terms of how they identify PHP usage and what version is being used. I'd have though that if you looked at their PHP page there should be a not insignificant number where they can reasonably guess it's using PHP (due to file extensions in URLs perhaps) but not be able to identify the version being used.
I wonder how much your "% of installs that are secure" statistic could be inaccurate due to most (I'd hope) sites that care even slightly about security suppressing the Apache header PHP version information. Are they just missing from the W3Tech stats? It's possible that a significant number of the "secure" PHP installs could be invisible to your calculations because the sort of people who keep their software up to date are the same people who follow fairly basic server set up recommendations.
I suppose there are also questions as to what "insecure" means in practice. For bulk hosting sites running unknown third party code everything is critical but for a lot of sites running their own code whether they are actually "insecure" depends not only on what PHP does but also what their code does. Eg for the most recent PHP 5.4 release there is a fix for a fairly nasty looking bug in unserialize(), but (as I understand it) a site admin with a defined codebase might quite legitimately determine that they never use unserialize() on user generated data and not be in any rush to update if they have other things to be doing. PHP version 5.4.35 might be "insecure" for the purposes of your stats but may not be in practice someone's server if they know they don't use unserialize() in an exploitable fashion (or mcrypt).
None of the above should be interpreted as criticism of your analysis, just food for thought. I find what you have done very interesting and expect that even if there are 'hidden' secure servers, the number of insecure ones would still be alarmingly high. -
Re:Why so high?
I think you need to read up on what the system does instead of blindly following it.
PHP used to use the crypt() function, which would generate a DES or MD5 hash. In PHP 5.5 they introduced the password_hash function to replace this, but it has a mode that generates backward-compatible crypt() style hashes, so if you pass the wrong arguments to it, you will be generating md5 (or worse) hashes.
I don't mean to sound rude (even though you did say you thought I knew "fuck all") but you really need to understand what you're doing. Saying "I used password_hash so I'm golden" just isn't good enough for security. This why I repeat, storing your passwords so they are not accessible is the only solution - as far as both of us know, you've been storing your passwords in something not far off plain text anyway.
To be fair you probably are using bcrypt, but don't keep thinking that's a done deal either - this guy shows you why you should not use bcrypt
-
Re:Why so high?
I think you need to read up on what the system does instead of blindly following it.
PHP used to use the crypt() function, which would generate a DES or MD5 hash. In PHP 5.5 they introduced the password_hash function to replace this, but it has a mode that generates backward-compatible crypt() style hashes, so if you pass the wrong arguments to it, you will be generating md5 (or worse) hashes.
I don't mean to sound rude (even though you did say you thought I knew "fuck all") but you really need to understand what you're doing. Saying "I used password_hash so I'm golden" just isn't good enough for security. This why I repeat, storing your passwords so they are not accessible is the only solution - as far as both of us know, you've been storing your passwords in something not far off plain text anyway.
To be fair you probably are using bcrypt, but don't keep thinking that's a done deal either - this guy shows you why you should not use bcrypt
-
Re:"could be worse than Heartbleed"
any CGI program + any non-Debian Linux => vulnerable
No, only CGI programs that use system/popen/etc to call out to things that may be bash.
Enh, good luck auditing even just a resonably complex CGI program for direct and indirect invocations of the system shell.
For instance, care to guess whether this one is safe?
For once, the PHP programmers are ahead security wise due to the ubiquity of mod_php...)
Well for one most languages the equivalent facility is available and usually used since it is a requirement to scale.
I know, mod_perl and mod_wsgi on Apache, and of course, Fast CGI. But CGI is still common in a lot of setups.
For another, even the silly 'fork and exec' perl or php or python isn't vulnerable if said script avoids system/popen/backticks/whathaveyou.
Even if you don't call out to the shell yourself, the standard library might.
Pop quiz 1: How is the PHP mail function implemented?
Pop quiz 2: What parts of the Python standard library module uuid are safe to use, and what parts will render your CGI script vulnerable?
I guess I was wrong to play down the severity of bash, but my hope was for people to just consider themselves to make a mistake by ever potentially having bash in a cgi context, for reasons beyond this exploit.
It's the system shell. It's everywhere. The real lesson here is to not use a big bulky program like Bash as the system shell.
Answers to pop quiz:
1. popen to execute sendmail program.
2. The following Python CGI script is vulnerable: import uuid (that's it). (uuid uses ctypes.util.find_library, which uses popen).
These examples took me less than 20 minutes of grepping to come up with, and I'm not even trying to hack any computers...
-
Re:"could be worse than Heartbleed"
any CGI program + any non-Debian Linux => vulnerable
No, only CGI programs that use system/popen/etc to call out to things that may be bash.
Enh, good luck auditing even just a resonably complex CGI program for direct and indirect invocations of the system shell.
For instance, care to guess whether this one is safe?
For once, the PHP programmers are ahead security wise due to the ubiquity of mod_php...)
Well for one most languages the equivalent facility is available and usually used since it is a requirement to scale.
I know, mod_perl and mod_wsgi on Apache, and of course, Fast CGI. But CGI is still common in a lot of setups.
For another, even the silly 'fork and exec' perl or php or python isn't vulnerable if said script avoids system/popen/backticks/whathaveyou.
Even if you don't call out to the shell yourself, the standard library might.
Pop quiz 1: How is the PHP mail function implemented?
Pop quiz 2: What parts of the Python standard library module uuid are safe to use, and what parts will render your CGI script vulnerable?
I guess I was wrong to play down the severity of bash, but my hope was for people to just consider themselves to make a mistake by ever potentially having bash in a cgi context, for reasons beyond this exploit.
It's the system shell. It's everywhere. The real lesson here is to not use a big bulky program like Bash as the system shell.
Answers to pop quiz:
1. popen to execute sendmail program.
2. The following Python CGI script is vulnerable: import uuid (that's it). (uuid uses ctypes.util.find_library, which uses popen).
These examples took me less than 20 minutes of grepping to come up with, and I'm not even trying to hack any computers...
-
Re:Six identifiable bullet points
The keyword to enable these changes in Python is from __future__ import . Seven features were introduced during Python 2.x: nested_scopes, generators (which added the keyword yield), division, absolute_import, with_statement (which added the keyword with), print_function (which removed the keyword print), and unicode_literals. Some already default on since 2.6 (nested_scopes, generators, and with_statement). In each case, there's a transition period when a module can choose one behavior or the other, and a module expecting one behavior can call a module expecting another behavior. The only breaking change that doesn't allow this sort of mixing is 2.x to 3.x. No breaking changes that I'm aware of have been introduced in Python 3.x since Python 3.0.
I went through the PHP migration guides and listed incompatible changes to the language itself: 5.1 to 5.2 (change to behavior of $value % 0, change to object-to-string conversion semantics), 5.2 to 5.3 (fatal error when passing a value to a function expecting a reference instead of creating a temporary anonymous variable, change to handling of $this in call_user_func_array(), and some new reserved keywords), and 5.3 to 5.4 (removal of call-time pass-by-reference, removal of computed break and continue statements, and some new reserved keywords). And at all times, all programs must use the syntax and semantics of the installed version of PHP.
-
Re:Six identifiable bullet points
The keyword to enable these changes in Python is from __future__ import . Seven features were introduced during Python 2.x: nested_scopes, generators (which added the keyword yield), division, absolute_import, with_statement (which added the keyword with), print_function (which removed the keyword print), and unicode_literals. Some already default on since 2.6 (nested_scopes, generators, and with_statement). In each case, there's a transition period when a module can choose one behavior or the other, and a module expecting one behavior can call a module expecting another behavior. The only breaking change that doesn't allow this sort of mixing is 2.x to 3.x. No breaking changes that I'm aware of have been introduced in Python 3.x since Python 3.0.
I went through the PHP migration guides and listed incompatible changes to the language itself: 5.1 to 5.2 (change to behavior of $value % 0, change to object-to-string conversion semantics), 5.2 to 5.3 (fatal error when passing a value to a function expecting a reference instead of creating a temporary anonymous variable, change to handling of $this in call_user_func_array(), and some new reserved keywords), and 5.3 to 5.4 (removal of call-time pass-by-reference, removal of computed break and continue statements, and some new reserved keywords). And at all times, all programs must use the syntax and semantics of the installed version of PHP.
-
Re:Six identifiable bullet points
The keyword to enable these changes in Python is from __future__ import . Seven features were introduced during Python 2.x: nested_scopes, generators (which added the keyword yield), division, absolute_import, with_statement (which added the keyword with), print_function (which removed the keyword print), and unicode_literals. Some already default on since 2.6 (nested_scopes, generators, and with_statement). In each case, there's a transition period when a module can choose one behavior or the other, and a module expecting one behavior can call a module expecting another behavior. The only breaking change that doesn't allow this sort of mixing is 2.x to 3.x. No breaking changes that I'm aware of have been introduced in Python 3.x since Python 3.0.
I went through the PHP migration guides and listed incompatible changes to the language itself: 5.1 to 5.2 (change to behavior of $value % 0, change to object-to-string conversion semantics), 5.2 to 5.3 (fatal error when passing a value to a function expecting a reference instead of creating a temporary anonymous variable, change to handling of $this in call_user_func_array(), and some new reserved keywords), and 5.3 to 5.4 (removal of call-time pass-by-reference, removal of computed break and continue statements, and some new reserved keywords). And at all times, all programs must use the syntax and semantics of the installed version of PHP.
-
Re:Six identifiable bullet points
No way to turn off the language's loosely-typed comparisons.
I disagree with the first point, for obvious reasons.
True, there's a strict counterpart to ==, namely ===. But what's the strict counterpart to < or switch?
PHP allows the server operator to change program semantics in ways that are annoying to work around, such as not allowing a shared hosting subscriber to turn off "magic quotes" or not following HTTP redirects in libcurl.
[This] is not a language issue.
In PHP, if you write a program, how can you be sure that it will work as intended with whatever combination of php.ini settings happens to be in effect on the server on which you deploy the program? For example, if I use the LightOpenID library to authenticate users on a server that has open_basedir set, attempts to authenticate users coming from Yahoo! will fail because Yahoo! implements OpenID with an HTTP redirect and for some inscrutable reason, libcurl refuses to follow HTTP redirects if open_basedir is set.
PHP versions change the semantics of existing programs in ways that encourage shared hosting providers to continue to offer only outdated versions of PHP, making it impossible for web application developers to take advantage of new features.
[This] would need some clarification as it's completely unsupported.
With the MySQLi extension, the only way to bind a variable number of arguments to a prepared statement is by passing an array of references to the statement's bind_param() method using call_user_func_array(). The way this has to be done changed in PHP 5.4, as described in the PHP manual's page about call_user_func_array() . The only workaround I can find for the difference in behavior between PHP 5.3, which is still supported on RHEL 6, and PHP 5.4 and later is to port the entire application to use a library that doesn't use call_user_func_array() in the first place, such as replacing all use of MySQLi with PDO. This can be a pain for a large application. For more information, see Breaking changes in PHP 5.3 and Breaking changes in PHP 5.4. Other languages have managed minor version changes better.
Parse errors and undefined function errors are fatal rather than throwing an exception that the caller can catch.
[This] doesn't make sense to me. How many languages throw an exception on a parse error?
I want to be able to do try { include_once("some_file.php"); } catch (SyntaxError $e) {
Further, he seems to hate the fact that PHP doesn't have MORE fatal errors.
Then let him use the warning-to-ErrorException snippet in the manual to turn warnings into exceptions that can be caught or left unhandled as needed.
I'm convinced that he'd complain, as he did in other cases, if a parse error *wasn't* fatal.
If a parse error threw an exception, this would satisfy both him (who wants things to be fatal by default) and me (who wants things to be not-fatal by choice).
-
Re:Six identifiable bullet points
No way to turn off the language's loosely-typed comparisons.
I disagree with the first point, for obvious reasons.
True, there's a strict counterpart to ==, namely ===. But what's the strict counterpart to < or switch?
PHP allows the server operator to change program semantics in ways that are annoying to work around, such as not allowing a shared hosting subscriber to turn off "magic quotes" or not following HTTP redirects in libcurl.
[This] is not a language issue.
In PHP, if you write a program, how can you be sure that it will work as intended with whatever combination of php.ini settings happens to be in effect on the server on which you deploy the program? For example, if I use the LightOpenID library to authenticate users on a server that has open_basedir set, attempts to authenticate users coming from Yahoo! will fail because Yahoo! implements OpenID with an HTTP redirect and for some inscrutable reason, libcurl refuses to follow HTTP redirects if open_basedir is set.
PHP versions change the semantics of existing programs in ways that encourage shared hosting providers to continue to offer only outdated versions of PHP, making it impossible for web application developers to take advantage of new features.
[This] would need some clarification as it's completely unsupported.
With the MySQLi extension, the only way to bind a variable number of arguments to a prepared statement is by passing an array of references to the statement's bind_param() method using call_user_func_array(). The way this has to be done changed in PHP 5.4, as described in the PHP manual's page about call_user_func_array() . The only workaround I can find for the difference in behavior between PHP 5.3, which is still supported on RHEL 6, and PHP 5.4 and later is to port the entire application to use a library that doesn't use call_user_func_array() in the first place, such as replacing all use of MySQLi with PDO. This can be a pain for a large application. For more information, see Breaking changes in PHP 5.3 and Breaking changes in PHP 5.4. Other languages have managed minor version changes better.
Parse errors and undefined function errors are fatal rather than throwing an exception that the caller can catch.
[This] doesn't make sense to me. How many languages throw an exception on a parse error?
I want to be able to do try { include_once("some_file.php"); } catch (SyntaxError $e) {
Further, he seems to hate the fact that PHP doesn't have MORE fatal errors.
Then let him use the warning-to-ErrorException snippet in the manual to turn warnings into exceptions that can be caught or left unhandled as needed.
I'm convinced that he'd complain, as he did in other cases, if a parse error *wasn't* fatal.
If a parse error threw an exception, this would satisfy both him (who wants things to be fatal by default) and me (who wants things to be not-fatal by choice).
-
Re:Six identifiable bullet points
No way to turn off the language's loosely-typed comparisons.
I disagree with the first point, for obvious reasons.
True, there's a strict counterpart to ==, namely ===. But what's the strict counterpart to < or switch?
PHP allows the server operator to change program semantics in ways that are annoying to work around, such as not allowing a shared hosting subscriber to turn off "magic quotes" or not following HTTP redirects in libcurl.
[This] is not a language issue.
In PHP, if you write a program, how can you be sure that it will work as intended with whatever combination of php.ini settings happens to be in effect on the server on which you deploy the program? For example, if I use the LightOpenID library to authenticate users on a server that has open_basedir set, attempts to authenticate users coming from Yahoo! will fail because Yahoo! implements OpenID with an HTTP redirect and for some inscrutable reason, libcurl refuses to follow HTTP redirects if open_basedir is set.
PHP versions change the semantics of existing programs in ways that encourage shared hosting providers to continue to offer only outdated versions of PHP, making it impossible for web application developers to take advantage of new features.
[This] would need some clarification as it's completely unsupported.
With the MySQLi extension, the only way to bind a variable number of arguments to a prepared statement is by passing an array of references to the statement's bind_param() method using call_user_func_array(). The way this has to be done changed in PHP 5.4, as described in the PHP manual's page about call_user_func_array() . The only workaround I can find for the difference in behavior between PHP 5.3, which is still supported on RHEL 6, and PHP 5.4 and later is to port the entire application to use a library that doesn't use call_user_func_array() in the first place, such as replacing all use of MySQLi with PDO. This can be a pain for a large application. For more information, see Breaking changes in PHP 5.3 and Breaking changes in PHP 5.4. Other languages have managed minor version changes better.
Parse errors and undefined function errors are fatal rather than throwing an exception that the caller can catch.
[This] doesn't make sense to me. How many languages throw an exception on a parse error?
I want to be able to do try { include_once("some_file.php"); } catch (SyntaxError $e) {
Further, he seems to hate the fact that PHP doesn't have MORE fatal errors.
Then let him use the warning-to-ErrorException snippet in the manual to turn warnings into exceptions that can be caught or left unhandled as needed.
I'm convinced that he'd complain, as he did in other cases, if a parse error *wasn't* fatal.
If a parse error threw an exception, this would satisfy both him (who wants things to be fatal by default) and me (who wants things to be not-fatal by choice).
-
Re:Six identifiable bullet points
No way to turn off the language's loosely-typed comparisons.
I disagree with the first point, for obvious reasons.
True, there's a strict counterpart to ==, namely ===. But what's the strict counterpart to < or switch?
PHP allows the server operator to change program semantics in ways that are annoying to work around, such as not allowing a shared hosting subscriber to turn off "magic quotes" or not following HTTP redirects in libcurl.
[This] is not a language issue.
In PHP, if you write a program, how can you be sure that it will work as intended with whatever combination of php.ini settings happens to be in effect on the server on which you deploy the program? For example, if I use the LightOpenID library to authenticate users on a server that has open_basedir set, attempts to authenticate users coming from Yahoo! will fail because Yahoo! implements OpenID with an HTTP redirect and for some inscrutable reason, libcurl refuses to follow HTTP redirects if open_basedir is set.
PHP versions change the semantics of existing programs in ways that encourage shared hosting providers to continue to offer only outdated versions of PHP, making it impossible for web application developers to take advantage of new features.
[This] would need some clarification as it's completely unsupported.
With the MySQLi extension, the only way to bind a variable number of arguments to a prepared statement is by passing an array of references to the statement's bind_param() method using call_user_func_array(). The way this has to be done changed in PHP 5.4, as described in the PHP manual's page about call_user_func_array() . The only workaround I can find for the difference in behavior between PHP 5.3, which is still supported on RHEL 6, and PHP 5.4 and later is to port the entire application to use a library that doesn't use call_user_func_array() in the first place, such as replacing all use of MySQLi with PDO. This can be a pain for a large application. For more information, see Breaking changes in PHP 5.3 and Breaking changes in PHP 5.4. Other languages have managed minor version changes better.
Parse errors and undefined function errors are fatal rather than throwing an exception that the caller can catch.
[This] doesn't make sense to me. How many languages throw an exception on a parse error?
I want to be able to do try { include_once("some_file.php"); } catch (SyntaxError $e) {
Further, he seems to hate the fact that PHP doesn't have MORE fatal errors.
Then let him use the warning-to-ErrorException snippet in the manual to turn warnings into exceptions that can be caught or left unhandled as needed.
I'm convinced that he'd complain, as he did in other cases, if a parse error *wasn't* fatal.
If a parse error threw an exception, this would satisfy both him (who wants things to be fatal by default) and me (who wants things to be not-fatal by choice).
-
Re:Perl still works, and PHP is fine
Judging by the fact that most of Facebook is based on PHP, it sounds to me like it's pretty robust... It's also object oriented.
And functional
The only drawback that I would find as a code-geek is weak typing
Which Facebook is addressing with their language Hack, which is heavily based on the PHP language. As a bonus, you also get a language that's built from the ground-up to be fully functional with their HHVM technology. It's an exciting time for PHP.
-
Re:PHP?
Dude, you are the one who's flat out wrong. Not only C has transitive relationship operators, but the language specification actually states that value comparison operators must be transitive except in cases where precision is lost in type-casting of operands.
So, for example, this might fool the typical PHP developer...
int main(void) {
unsigned long a = 98765UL;
int b = -12345;
short c = 1;if (a < b) printf("a < b!\n");
if (b < c) printf("b < c!\n");
if (c < a) printf("c < a!\n");
}int main(void) {
unsigned long a = 98765UL;
int b = -12345;
short c = 1;if (a < (long)b) printf("a < b!\n");
if (b < (int)c) printf("b < c!\n");
if (c < (short)a) printf("c < a!\n");
}Compare this to the brainfuck that is PHP, where comparison rules are well stablished but still manage to produce this crap. I can't believe i'm actually discussing this.
-
Re:PHP?
Oh, and by the way. Why do people insists on comparing PHP to C? Isn't PHP supposed to be a high-level, website oriented scripting language?
I ask because i've seen bugs about PHP segfaulting reliably rejected only because "this behavior is consistent with what lower level languages like C do". It's like watching an exploit slowly growing from its infancy.
-
Re:Imaginary numbers, imaginary criticisms
-
Imaginary numbers, imaginary criticisms
If you're doing complex math with PHP you're doing something horribly wrong.
Then why does PEAR have a class specifically for complex math?
-
Re:I got tired of waiting
It lulls you into a false sense of security by not throwing errors or warnings with its ultra-lax dynamic typing.
Unless you do like me and decide early on to convert warnings to ErrorException . Sure, there are a few wrinkles, such as the fact that the string '0' is falsey, the fact that comparison operators tend to cast strings to integer, and the inconsistent naming of much of the standard library. But PHP 5.4 and 5.5 have cleaned up the language itself somewhat. One problem is that a lot of shared web hosting providers still deploy outdated PHP versions.
-
Re:I got tired of waiting
string $number
Warning base_convert() may lose precision on large numbers due to properties related to the internal "double" or "float" type used.
Yeah, great example there. That wasn't even a random example, that was an example you picked to show PHP in a favorable light.
PHP is a total clusterfuck of bad design, and base_convert() is just yet another example.
-
Re:real_foo_bar() and somesuch_improved()
mysql_real_escape_string is a wrapper of a C function. Does that make C the laughing stock for you as well?
Wrapping your house in toilet paper would make your house a laughing stock
-
Re:real_foo_bar() and somesuch_improved()
mysql_real_escape_string is a wrapper of a C function. Does that make C the laughing stock for you as well?
I keep saying this on Slashdot: PHP has it's weaknesses, but inconsistent naming conventions isn't a major problem. What made PHP the laughing stock is looking at incompetent coders' code and thinking that's how you do things in PHP.
PHP is a good language for web development. It has an easy learning curve and gives you power to shoot yourself in the foot. Combine those two and you get a bunch of atrocious code floating around the web from the hands of incompetent. But you also get rapid development with very readable code where new programmers can easily jump in in the hands of competent.
P.S. mysql_real_escape_string is now deprecated. PHP has come a long way since its atrocious beginnings and TFA talks about that (clue is in the title). -
Re:bacony
