Hi all,
This PR seems good fix for 5.6.
https://github.com/php/php-src/pull/463
Test script:
$a = ''; // empty string
$a[10] = 'a';
echo $a; // "Array"
$b = ' '; // non empty string
$b[10] = 'b';
echo $b; // " b"
Expected result:
" a"
" b"
Actual result:
"Array"
" b"
Current behavior does not make sense.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi all,
This PR seems good fix for 5.6.
https://github.com/php/php-src/pull/463
Test script:
$a = ''; // empty string
$a[10] = 'a';
echo $a; // "Array"$b = ' '; // non empty string
$b[10] = 'b';
echo $b; // " b"Expected result:
" a"
" b"Actual result:
"Array"
" b"Current behavior does not make sense.
The current behavior is that anything "falsey" (e.g. null, false and the
empty string) is silently cast to array when an array operation is applied
to it. I don't like that behavior, but it's somewhat internally consistent
now. Changing it for strings only seems a bit weird.
Nikita
Hi Nikita,
The current behavior is that anything "falsey" (e.g. null, false and the
empty string) is silently cast to array when an array operation is applied
to it. I don't like that behavior, but it's somewhat internally consistent
now. Changing it for strings only seems a bit weird.
Persuasive argument.
I prefer to change the behavior if I have to choose, though.
$a = ''; // empty string
$a[10] = 'a';
echo $a; // "Array"
would be common pit hole when users are trying to use string as array of
chars.
I don't know why, but there are 436 FB likes! for this PR even if there is
no "likes!"
button on the page. There may be a lot of users that are unhappy with this
behavior.
Document and warn users?
Or should we change behavior even if it seems odd?
I don't mind at all setting up RFC to vote.
Any comments?
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi all,
I don't know why, but there are 436 FB likes! for this PR even if there is
no "likes!"
button on the page. There may be a lot of users that are unhappy with
this behavior.
The number of likes! are the same as "php-src".
I guess Facebook is ignoring the path :)
Anyway, are we going to document the behavior?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Nikita,
The current behavior is that anything "falsey" (e.g. null, false and the
empty string) is silently cast to array when an array operation is applied
to it. I don't like that behavior, but it's somewhat internally consistent
now. Changing it for strings only seems a bit weird.Persuasive argument.
I prefer to change the behavior if I have to choose, though.$a = ''; // empty string
$a[10] = 'a';
echo $a; // "Array"
Just my 2 cents, but that definitely looks like a situation that might
crop up in real code unintentionally, and it violates the Principle of
Least Astonishment IMO. Consider a hypothetical function which returns a
modified string. If we've ended up with an empty string being passed
into it, then it suddenly returning an Array is not what you expect, and
might horribly break code that assumes the result won't be a string.
--
Andrea Faulds
http://ajf.me/
Just my 2 cents, but that definitely looks like a situation that might
crop up in real code unintentionally, and it violates the Principle of
Least Astonishment IMO. Consider a hypothetical function which returns a
modified string. If we've ended up with an empty string being passed
into it, then it suddenly returning an Array is not what you expect, and
might horribly break code that assumes the result won't be a string.
Oh dear Andrea, you should proofread your emails better.
s/won't be/will be
--
Andrea Faulds
http://ajf.me/
Hi Andrea,
Just my 2 cents, but that definitely looks like a situation that might
crop up in real code unintentionally, and it violates the Principle of
Least Astonishment IMO. Consider a hypothetical function which returns a
modified string. If we've ended up with an empty string being passed
into it, then it suddenly returning an Array is not what you expect, and
might horribly break code that assumes the result won't be a string.Oh dear Andrea, you should proofread your emails better.
s/won't be/will be
I agree with your discussion and that's the reason why I sending
this PR before I said "it's the spec".
I've added this behavior to RFC (NOT for voting)
https://wiki.php.net/rfc/comparison_inconsistency?&#conversioncomparison
I'm gathering these kind of PHP behaviors. If you have one, please let me
know so that I can add issues in the wiki page. (Or even better, please add
one to the page)
Thank you.
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi!
I've added this behavior to RFC (NOT for voting)
https://wiki.php.net/rfc/comparison_inconsistency?&#conversioncomparison
I'm not sure behavior that is documented and implemented exactly as it
was planned (e.g. min() behavior) can be called "inconsistency". It is
actually completely consistent and does exactly what it is meant to do.
Same for dec/hex strings - it works exactly like strtod(). Of course it
does not support every numeric base in existence, but it was never
supposed to.
Also, "Null string is not handled as string" is not correct - null
string is handled as string, except in one narrow case where you apply
array operations to it. Right now it gives an impression empty strings
are not handled as strings in PHP at all, which is not correct.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi Stas,
It might be better to change RFC title.
My goal is sort out PHP behaviors which may seem strange.
If it's a bug, fix it. if not, document it so that users understand
what it suppose to do.
On Fri, Nov 22, 2013 at 4:49 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
I've added this behavior to RFC (NOT for voting)
https://wiki.php.net/rfc/comparison_inconsistency?&#conversioncomparisonI'm not sure behavior that is documented and implemented exactly as it
was planned (e.g.min()behavior) can be called "inconsistency". It is
actually completely consistent and does exactly what it is meant to do.
Same for dec/hex strings - it works exactly like strtod(). Of course it
does not support every numeric base in existence, but it was never
supposed to.
I agree. It's the way PHP works.
It might be better to document these, since there are many languages out
there and people have different expectations.
Also, "Null string is not handled as string" is not correct - null
string is handled as string, except in one narrow case where you apply
array operations to it. Right now it gives an impression empty strings
are not handled as strings in PHP at all, which is not correct.
I've updated to
"Null string is handled as array" when string is accessed as array of char.
I appreciate better explanation :)
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Stas,
It might be better to change RFC title.
My goal is sort out PHP behaviors which may seem strange.If it's a bug, fix it. if not, document it so that users understand
what it suppose to do.
I've changed the title to
RFC: Existing comparison and conversion behaviors to discuss/document
https://wiki.php.net/rfc/comparison_inconsistency
This title might be better than old one.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net