Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99819
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.46 as permitted sender)
MIME-Version: 1.0
Date: Sat, 8 Jul 2017 11:30:55 +1200
Message-ID: <CAHFNTwefWVRC+ZXryeJ31uDDkeRNTOu4ZqWqf5HW3_fOmJ8EOQ@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="001a11408616efb8630553c29f3e"
Subject: ArrayAccess: Constant numeric string offsets become integers
From: rtheunissen@php.net (Rudi Theunissen)

--001a11408616efb8630553c29f3e
Content-Type: text/plain; charset="UTF-8"

Bug:  https://bugs.php.net/bug.php?id=63217
PR:   https://github.com/php/php-src/pull/2607
Demo: https://3v4l.org/dagUP

I've heard mixed responses to this bug and the approach to fix it (or
whether we should at all). The two common opinions are that ArrayAccess
should behave exactly like an array, and the other is that it's up to the
implementer to handle the offsets.

I would like to propose that the aim of ArrayAccess is not to emulate the
*behaviour* of an array, but instead only use its access *syntax*. The way
an array handles numeric string keys, floats, booleans etc is specific to
how an array works, and should not be forced on objects that implement
ArrayAccess.

In the demo linked above, you'll notice that ArrayAccess already allows any
key type, but becomes inconsistent when a constant numeric string is used.
Notice that the HHVM result shows the expected behaviour.

We should either go full array behaviour, or full array syntax only. The
numeric string optimisation that causes this bug is broken and should
either be fixed or removed entirely.

An important note is that *this does not affect arrays or object properties
at all* - only ArrayAccess.

--001a11408616efb8630553c29f3e--