FAQ
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

Search Discussions

  • Nikita Popov at Nov 20, 2013 at 3:26 pm

    On Wed, Nov 20, 2013 at 12:47 AM, Yasuo Ohgaki wrote:

    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
  • Yasuo Ohgaki at Nov 20, 2013 at 9:38 pm
    Hi Nikita,
    On Thu, Nov 21, 2013 at 12:26 AM, Nikita Popov wrote:

    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
  • Yasuo Ohgaki at Nov 20, 2013 at 9:49 pm
    Hi all,
    On Thu, Nov 21, 2013 at 6:38 AM, Yasuo Ohgaki wrote:

    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
  • Andrea Faulds at Nov 20, 2013 at 9:49 pm

    On 20/11/13 21:38, Yasuo Ohgaki wrote:
    Hi Nikita,
    On Thu, Nov 21, 2013 at 12:26 AM, Nikita Popov wrote:

    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/
  • Andrea Faulds at Nov 20, 2013 at 9:53 pm

    On 20/11/13 21:49, Andrea Faulds wrote:
    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/
  • Yasuo Ohgaki at Nov 20, 2013 at 10:02 pm
    Hi Andrea,
    On Thu, Nov 21, 2013 at 6:53 AM, Andrea Faulds wrote:
    On 20/11/13 21:49, Andrea Faulds wrote:


    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
  • Stas Malyshev at Nov 21, 2013 at 7:49 pm
    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
  • Yasuo Ohgaki at Nov 22, 2013 at 12:28 am
    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 wrote:

    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.
    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
  • Yasuo Ohgaki at Nov 22, 2013 at 1:44 am
    Hi Stas,
    On Fri, Nov 22, 2013 at 9:27 AM, Yasuo Ohgaki wrote:

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedNov 19, '13 at 11:48p
activeNov 22, '13 at 1:44a
posts10
users4
websitephp.net

People

Translate

site design / logo © 2022 Grokbase