I have been wondering the answer to this question for a while now. A LOT
of stuff has been backported from PHP 6 to PHP 5.3. So much in fact, why
don't you just call PHP 5.3 version 6?
What major new features are left for PHP 6? The big one I can think of
is unicode support and dropping some depreciated stuff. Yes, I have
looked at the wiki todo list for 6.
I'm not trying to start anything here, just want to know why not just
call it PHP 6?
I have been wondering the answer to this question for a while now. A
LOT of stuff has been backported from PHP 6 to PHP 5.3. So much in
fact, why don't you just call PHP 5.3 version 6?What major new features are left for PHP 6? The big one I can think
of is unicode support and dropping some depreciated stuff. Yes, I
have looked at the wiki todo list for 6.
Native unicode is not big enough for you?
regards,
Lukas
Lukas Kahwe Smith wrote:
Native unicode is not big enough for you?
regards,
Lukas
If you're looking for good PR and reviews, no. I think if you have very
limited new features, the people writing reviews are going to say PHP 6
doesn't have much new and not worth the upgrade. IMO
Honestly, I think PHP 5.3 is worthy of being called PHP 6. There are
certainly enough new features.
Lukas Kahwe Smith wrote:
Native unicode is not big enough for you?
regards,
LukasIf you're looking for good PR and reviews, no. I think if you have
very limited new features, the people writing reviews are going to
say PHP 6 doesn't have much new and not worth the upgrade. IMOHonestly, I think PHP 5.3 is worthy of being called PHP 6. There are
certainly enough new features.
Marketing is not our concern, and trust me .. native unicode is enough
to warrant a new major version because of the internal changes.
regards,
Lukas
I have been wondering the answer to this question for a while now. A LOT
of stuff has been backported from PHP 6 to PHP 5.3. So much in fact, why
don't you just call PHP 5.3 version 6?What major new features are left for PHP 6? The big one I can think of
is unicode support and dropping some depreciated stuff. Yes, I have
looked at the wiki todo list for 6.I'm not trying to start anything here, just want to know why not just
call it PHP 6?
Because it's just 5.2 + some additions and PHP6 (HEAD) is something entirely different?
Did you even try to compare the codebase?
--
Wbr,
Antony Dovgal
I'm thinking there must be a bug in the heart of php
causing this. I'll debug it, but I haven't looked at
php source code in a few years and would like a tip as
to which files are involved in evaluating "==". Here
is a fragment from my code and the output:
...
print "<pre>\n";
var_dump($max);
var_dump($nms);
var_dump($nms == $max);
$max = (float)$max;
$nms = (string)$nms;
var_dump($max);
var_dump($nms);
var_dump($nms == $max);
$max = (string)$max;
$nms = (float)$nms;
var_dump($max);
var_dump($nms);
var_dump($nms == $max);
print "</pre>\n";
...
string(3) "1.8"
float(1.8)
bool(false)
float(1.8)
string(3) "1.8"
bool(true)
string(3) "1.8"
float(1.8)
bool(true)
I found this using php 5.2.3. I just upgraded to php 5.2.5
and am receiving the exact same result. Obviously, I can't
reproduce it with a simple var_dump("1.8"==1.8). :(
I guess something is getting corrupted, and I will add debug
output until I find out what (or Murphy removes the problem
by adding debug output; then I'm not sure what I'll do).
Thanks for any tips on which files I should look at it.
Thanks,
Todd
There is no bug here. Please read:
http://docs.sun.com/source/806-3568/ncg_goldberg.html
-Rasmus
Todd Ruth wrote:
I'm thinking there must be a bug in the heart of php
causing this. I'll debug it, but I haven't looked at
php source code in a few years and would like a tip as
to which files are involved in evaluating "==". Here
is a fragment from my code and the output:...
print "<pre>\n";
var_dump($max);
var_dump($nms);
var_dump($nms == $max);
$max = (float)$max;
$nms = (string)$nms;
var_dump($max);
var_dump($nms);
var_dump($nms == $max);
$max = (string)$max;
$nms = (float)$nms;
var_dump($max);
var_dump($nms);
var_dump($nms == $max);
print "</pre>\n";
...string(3) "1.8"
float(1.8)
bool(false)
float(1.8)
string(3) "1.8"
bool(true)
string(3) "1.8"
float(1.8)
bool(true)I found this using php 5.2.3. I just upgraded to php 5.2.5
and am receiving the exact same result. Obviously, I can't
reproduce it with a simple var_dump("1.8"==1.8). :(
I guess something is getting corrupted, and I will add debug
output until I find out what (or Murphy removes the problem
by adding debug output; then I'm not sure what I'll do).Thanks for any tips on which files I should look at it.
I'd take that as proof of a design flaw in having php
doing string to float comparison by casting the string to
float instead of the float to a string, but you've got
me - the documentation does say the string will be converted
to a float and not vice-versa. If it wouldn't be a bad BC
break, I think there'd be a lower WTF by doing the cast
the other way. "==" means are they the same and "==="
means are they the SAME. With "==", '1.8' should match
any float that would be displayed as 1.8. (Of course,
with "===" they aren't even the same type, so you're
false from the start.) I say "should" from an anti-WTF
perspective. Again, I must bow to the spec and you have
me there.
Thanks for saving me the hours of discovering all this
via debugging. Please consider the switching of casts
for string==float for the suggestion box.
- Todd
There is no bug here. Please read:
http://docs.sun.com/source/806-3568/ncg_goldberg.html
-Rasmus
Todd Ruth wrote:
I'm thinking there must be a bug in the heart of php
causing this. I'll debug it, but I haven't looked at
php source code in a few years and would like a tip as
to which files are involved in evaluating "==". Here
is a fragment from my code and the output:...
print "<pre>\n";
var_dump($max);
var_dump($nms);
var_dump($nms == $max);
$max = (float)$max;
$nms = (string)$nms;
var_dump($max);
var_dump($nms);
var_dump($nms == $max);
$max = (string)$max;
$nms = (float)$nms;
var_dump($max);
var_dump($nms);
var_dump($nms == $max);
print "</pre>\n";
...string(3) "1.8"
float(1.8)
bool(false)
float(1.8)
string(3) "1.8"
bool(true)
string(3) "1.8"
float(1.8)
bool(true)I found this using php 5.2.3. I just upgraded to php 5.2.5
and am receiving the exact same result. Obviously, I can't
reproduce it with a simple var_dump("1.8"==1.8). :(
I guess something is getting corrupted, and I will add debug
output until I find out what (or Murphy removes the problem
by adding debug output; then I'm not sure what I'll do).Thanks for any tips on which files I should look at it.
Clicked Send too fast. For the suggestion box, let me
instead suggest that for string $s and float $f:
$s == $f (a string being compared to a float) be the same as
(string)(float)$s === (string)$f instead of
(float)$s === $f (as it is today if my understanding is correct)
Since the current behavior is effectively undefined in any
case in which the two interpretations would give different
results, I'd guess that change could probably be made without
breaking BC. The only problem would be if someone relied
on the change and their code was run on an old version of
php.
I'll go back to my corner now. Thanks for listening...
- Todd
I'd take that as proof of a design flaw in having php
doing string to float comparison by casting the string to
float instead of the float to a string, but you've got
me - the documentation does say the string will be converted
to a float and not vice-versa. If it wouldn't be a bad BC
break, I think there'd be a lower WTF by doing the cast
the other way. "==" means are they the same and "==="
means are they the SAME. With "==", '1.8' should match
any float that would be displayed as 1.8. (Of course,
with "===" they aren't even the same type, so you're
false from the start.) I say "should" from an anti-WTF
perspective. Again, I must bow to the spec and you have
me there.Thanks for saving me the hours of discovering all this
via debugging. Please consider the switching of casts
for string==float for the suggestion box.
- Todd
There is no bug here. Please read:
http://docs.sun.com/source/806-3568/ncg_goldberg.html
-Rasmus
Todd Ruth wrote:
I'm thinking there must be a bug in the heart of php
causing this. I'll debug it, but I haven't looked at
php source code in a few years and would like a tip as
to which files are involved in evaluating "==". Here
is a fragment from my code and the output:...
print "<pre>\n";
var_dump($max);
var_dump($nms);
var_dump($nms == $max);
$max = (float)$max;
$nms = (string)$nms;
var_dump($max);
var_dump($nms);
var_dump($nms == $max);
$max = (string)$max;
$nms = (float)$nms;
var_dump($max);
var_dump($nms);
var_dump($nms == $max);
print "</pre>\n";
...string(3) "1.8"
float(1.8)
bool(false)
float(1.8)
string(3) "1.8"
bool(true)
string(3) "1.8"
float(1.8)
bool(true)I found this using php 5.2.3. I just upgraded to php 5.2.5
and am receiving the exact same result. Obviously, I can't
reproduce it with a simple var_dump("1.8"==1.8). :(
I guess something is getting corrupted, and I will add debug
output until I find out what (or Murphy removes the problem
by adding debug output; then I'm not sure what I'll do).Thanks for any tips on which files I should look at it.