21–30 of 70 posts
When I read the new PHP spec, I threw up in my mouth after I saw that empty("0") was a special case of empty that returned TRUE. I know that's how PHP normally works, but that doesn't really make my mouth taste any better.
Critiquing the critique of Facebook's new PHP spec: You used affect when you should have used effect. They probably don't teach that in the CS PhD program:) Of course my post may be subject to Muphry's Law. But still. If you're going to spend so much time establishing your credibility, do you really want to ruin it by demonstrating you don't have a basic understanding of English grammar? http://en.wikipedia.org/wiki/…
Critiquing the critique of Facebook's new PHP spec: You used affect when you should have used effect. They probably don't teach that in the CS PhD program:) Of course my post may be subject to Muphry's Law. But still. If you're going to spend so much time establishing your credibility, do you really want to ruin it by demonstrating you don't have a basic understanding of English grammar? http://en.wikipedia.org/wiki/…
I'm not sure I would place any significance on something I have seen many native speakers screw up consistently. If you're not familiar with the author, you could take the time to read the blog post he linked to where he talked about HPHP and phc
Critiquing the critique of Facebook's new PHP spec: You used affect when you should have used effect. They probably don't teach that in the CS PhD program:) Of course my post may be subject to Muphry's Law. But still. If you're going to spend so much time establishing your credibility, do you really want to ruin it by demonstrating you don't have a basic understanding of English grammar? http://en.wikipedia.org/wiki/…
Earlier quoted context omitted.
I'm not sure I would place any significance on something I have seen many native speakers screw up consistently. If you're not familiar with the author, you could take the time to read the blog post he linked to where he talked about HPHP and phc
If the affect/effect error was in isolation it wouldn't have been a big deal. When combined with a rant of how much of an expert he was the contrast led to quite a bit of cognitive dissonance.
Earlier quoted context omitted.
I'm not sure I would place any significance on something I have seen many native speakers screw up consistently. If you're not familiar with the author, you could take the time to read the blog post he linked to where he talked about HPHP and phc
If the affect/effect error was in isolation it wouldn't have been a big deal. When combined with a rant of how much of an expert he was the contrast led to quite a bit of cognitive dissonance.
Earlier quoted context omitted.
EDIT: Brain fart; don't use this. See comments below. Just use the following if you really want to account for strings containing the number 0. (!isset($var) || $var === false); Note the triple equals sign.
This won't work. Both 0 (numeric) and '0' (string) == false, but never === false (because when you === you're checking that it's the same type). If you expect a string '0', simply check strlen($str) > 0. If the value could be numeric, use a (string) cast.
Earlier quoted context omitted.
That part of the spec refers to variables (which the spec calls VSlots), not objects (which the spec calls HStores). Objects have different lifetimes, and the spec actually allows the destructors to be run anytime between the object being dead and the program ending. So it looks like there won't be any RAII here.
No RAII would be a big change in the behavior of PHP; you should add that information to your critique. I have code that relies on RAII for error recovery and rollback. Any PHP implementation that doesn't do RAII is going to subtly break a lot of code. It doesn't make sense to force very specific memory lifetimes for variables and then also not do it for objects.
[0] it doesn't work when there's a cycle for instance
Earlier quoted context omitted.
It's in direct conflict with the PHP manual: http://php.net/manual/en/language.oop5.decon.php#language.oo... "PHP 5 introduces a destructor concept similar to that of other object-oriented languages, such as C++. The destructor method will be called as soon as there are no other references to a particular object, or in any order during the shutdown sequence." It's very common to rely on this behavior to do cleanup as…
I think we're talking at cross-purposes. I'm just saying that because it's underspecified, the Zend engine can be both accurate to what's in the PHP manual, and to what's in the spec. Anyway, it's a slightly pedantic point, so I'm probably not contributing much to the conversation here :)
PHP Code > PHP Spec > PHP Engine
To be fair, the JS spec may say those things but no modern JS engine actually does it that way. Despite the wording, "must appear to..." is the common interpretation of that spec. It is nice that this one makes that explicit, though.