21–30 of 217 posts
There's a lot of valid points there, but "#33 Cannot override private methods with a subclass" is the right behavior. That's exactly what private is for, and it's important to know that such names are non-colliding and you can rely on their implementation. Use protected for overridable methods. You shouldn't mock or directly test private methods in unit tests — they're not part of the interface!
I've definitely run into #1 on the list. "Paamayim Nekudotayim" is a transliterated version of פעמיים נקודתיים, which means "double colon" in Hebrew. Zeev and Andi are Israeli, which kind of explains it, but the error message is still pretty useless.
Pretend that English had no representation of an ellipsis, but Hebrew did. Should the language author say "Expected: dot-dot-dot" in the error message to appease native English speakers, or should (s)he use the unambiguous form?
Earlier quoted context omitted.
> making the switch in if() be a boolean only What exactly is the alternative? If there's any problem here it's automatic coercion.
Nothing wrong with automatic coercion, as long as the rules are sane. In ruby, everything except false and nil is true. Easy. Unless you override the == method of course. With great power...
For instance, 0 == false isn't too crazy, it's like C. But automatic coercion of string values to ints makes "0" == false which is sometimes what you want and sometimes not.
Practically this burns people in form validation code because often you want to test if a field is an empty string and if you do the obvious thing you can end up kicking out "0".
When I write PHP I have my own "PHP on nails" library that has functions that smooth out most of the things that are wrong with the language, and one of them is a comparison operator that is somewhere between "==" and "===" that most frequently does what you want it to do.
What makes me sad is that people will defend this horrible language to the death, regardless of how many problems there are with it. I don't get it; we know how bad PHP is, so why do people fight so hard? Oh, and to demonstrate: "PHP has no native Unicode type, no native Unicode handling, and cannot treat Unicode strings as strings." This true statement, composed of three observations about deficiencies in the langua…
I've definitely run into #1 on the list. "Paamayim Nekudotayim" is a transliterated version of פעמיים נקודתיים, which means "double colon" in Hebrew. Zeev and Andi are Israeli, which kind of explains it, but the error message is still pretty useless.
This should disappear soon[1], it seems the patch has been accepted (or is on a good way to be), according the internals@ mailing list[2]. [1] https://wiki.php.net/rfc/improved-parser-error-message [2] http://news.php.net/php.internals/52436
PHP's single greatest advantage is ubiquity - would love to see a CoffeeScript compiler for PHP that smooths out these issues.
you could say that all other web platforms are blub because they don't see the value that PHP brings to the table. a total idiot can install PHP and get a system that will meet the performance and reliability needs of 99.5 of web sites out there. tomcat, mod_perl, the ten different ways people host Ruby sites and all that make a lot more trouble for you. I've run PHP-based web servers for hundreds of sites that have…
http://www.getrailo.com/com/index.cfm/whyrailo/developers/
(Scroll to bottom where they address why for PHP devs)
Before everyone goes all "why don't you switch to language X or platform Y or lisp variant Z" I just want to say good job on this. These all seem to be sane critiques of PHP without being all doomsday world-ending inflamatory. Kudos. Also, I think that this is another example of how hard it is to build up a large and widely-used language/framework without having lots of warts. Especially since PHP wasn't originally d…
This happens to me while producing something like a jqGrid, or other javascript/html hybrid stuff that need a few extra options sometimes.
Django/Python? No problem! Just use the keywords you need.
(More Info: The difference between a single associative param standing in for keywords arguments, or a huge list of regular arguments is a choice in complexity/readability IN the function vs. calling it.
For the single dictionary approach, you lost the built-in parameter defaults nicety, which means you need to handle the case of a missing parameter manually. This kind of sucks, especially if you hate seeing PHP Notices during development (which kill JSON/XML output anyway). This makes your function often twice as big (or more) than it needs to be.
For the other approach, you wind up with calling
foo("","","","real value", true, true, 2, false, false, "option I want");*
What makes ME sad is no keyword arguments. Helper/wrapper functions either get an annoying and difficult-to-grok-at-glance associative-array for it's params (bad), or a huge list of rarely-used parameters (worse), or a huge set of wrapper functions to set their own paramters (even worse), or outright duplicated functions for similar-but-not-quite tasks (worst). This happens to me while producing something like a jqGr…
$foo = 123;
$bar = getSomeBar();
myFunction(compact('foo', 'bar'));
function myFunction($kwargs) {
$foo = SOME_DEFAULT_VALUE;
extract($kwargs);
if ($foo > 5) {
...
}
}
Nb., extract() works on any associative array, you don't have to use compact().