Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73319
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGAGxbZaO=JacTpJCe0g2f7TcKOnS0_x-sbF++h6uk2j1vFLEg@mail.gmail.com>
References: <CAHMUw2EzjCn36wAAGMuQq2HPQdo1uAtgR09Z8x5BXNPA_B8uoA@mail.gmail.com>
	<CAGAGxbZaO=JacTpJCe0g2f7TcKOnS0_x-sbF++h6uk2j1vFLEg@mail.gmail.com>
Date: Thu, 20 Mar 2014 10:48:50 +0800
Message-ID: <CAHMUw2Ejf6XeQNxs29rm+UfRbTX91umQBPQxYqd7jEY9+Jdamw@mail.gmail.com>
To: Chris Wright <cw@daverandom.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11339e2e223a6004f500cf4a
Subject: Re: [PHP-DEV] Re: Array dereference on scalar / null values
From: tjerk.meesters@gmail.com (Tjerk Meesters)

--001a11339e2e223a6004f500cf4a
Content-Type: text/plain; charset=ISO-8859-1

Hi Chris,


On Wed, Mar 19, 2014 at 5:21 PM, Chris Wright <cw@daverandom.com> wrote:

>
> 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.
>
The problem is that `list()` is not an opcode per se, but rather a code
generator; it generates assignment opcodes for each specified variable, so:

    list($key, $value) = each($array);

Gets compiled into:

    $tmp = each($array);
    $key = $tmp[0];
    $value = $tmp[1];

From what I gather, what you have proposed only has a chance of working if
the compiler could be told to perform the assignment and silently discard
any issues that arise from doing an array dereference on something that's
not an array (or object that looks like an array).

Perhaps that's possible, I'm not sure :)

>
> > Best,
> >   Jack
>



-- 
--
Tjerk

--001a11339e2e223a6004f500cf4a--