Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73299
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.174 as permitted sender)
MIME-Version: 1.0
Sender: are.you.winning@gmail.com
In-Reply-To: <CAHMUw2EzjCn36wAAGMuQq2HPQdo1uAtgR09Z8x5BXNPA_B8uoA@mail.gmail.com>
References: <CAHMUw2EzjCn36wAAGMuQq2HPQdo1uAtgR09Z8x5BXNPA_B8uoA@mail.gmail.com>
Date: Wed, 19 Mar 2014 09:21:44 +0000
Message-ID: <CAGAGxbZaO=JacTpJCe0g2f7TcKOnS0_x-sbF++h6uk2j1vFLEg@mail.gmail.com>
To: Tjerk Meesters <tjerk.meesters@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0149d2f67e173604f4f22e50
Subject: Re: [PHP-DEV] Re: Array dereference on scalar / null values
From: cw@daverandom.com (Chris Wright)

--089e0149d2f67e173604f4f22e50
Content-Type: text/plain; charset=ISO-8859-1

On 18 Mar 2014 06:17, "Tjerk Meesters" <tjerk.meesters@gmail.com> wrote:
>
> Hi internals,
>
> I've done some bug report gathering on essentially the following
behaviour:
>
> $a = 123; var_dump($a[1]); // "NULL"
> $b = true; var_dump($b[1]); // "NULL"
> $f = fopen('file', 'r'); var_dump($f[1]); // "NULL"
> $n = null; var_dump($n[1]); // "NULL"
>
> Bug reports:
>
> https://bugs.php.net/bug.php?id=37676
> https://bugs.php.net/bug.php?id=40692
> https://bugs.php.net/bug.php?id=62769
> https://bugs.php.net/bug.php?id=64194
> https://bugs.php.net/bug.php?id=65484
>
> From the comments it seems that there's some disagreement within the
group,
> for example:
>
> Nikita: "I would tentatively classify this as a bug."
> Tony: "Reclassified as feature request.."
> Xinchen: "there was a similar bug report of this behavior, and I seems
made
> a fix for it."
> Ilia: "this is not a bug." x 2
> Joe: "it is the only reasonable thing _to expect_"
>
> From my understanding, developers are expecting to see notices when this
> happens, something like "Cannot use integer/boolean/resource/null as array
> in %s on line %d"; I think they're okay with the fact that the end result
> will still be "NULL", though.
>
> The `list()` operator has since complicated matters; if we would indeed
> introduce notices as requested, the following code would cause issues:
>
> $array = [1, 2, 3];
> while (list($key, $value) = each($array)) {
>     echo "$key = $value\n";
> }
>
> The return value of `each()` - as it has reached the end of an array - is
> `false`, so the above code would show two notices. Unfortunately, we must
> assume that all code in the manual are actually used and so it would
surely
> break stuff when introduced.
>
> We could mitigate this issue by having `each()` return `null` instead and
> introduce notices for all other scalars, but this code is not unlikely:
>
> while (($data = each($array)) !== false) {
>     echo "${data[0]} = ${data[1]}\n";
> }
>
> So my question is, how should we handle this? Close all bug reports and
add
> something to the documentation? Allow array dereference only on booleans
> *and* `null`?
>

The alternative is treating list() as the special case and suppressing the
error there. I'd prefer this over allowing bool/null to be dereferenced
silently in the general case, since it would keep the special handling
where it belongs - I.e. where the conflict is.

>
> Best,
>   Jack

--089e0149d2f67e173604f4f22e50--