Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108050
MIME-Version: 1.0
References: <CAF+90c-e7P5RZqEABgT=QDtEAC3wuPRjn6ysKQu15=7GJ09J5A@mail.gmail.com>
 <CALKiJKqsJZ85kCdk-w6ZFs8a2YbnuBJr+LbpLVqxrKkh5y0SwQ@mail.gmail.com>
In-Reply-To: <CALKiJKqsJZ85kCdk-w6ZFs8a2YbnuBJr+LbpLVqxrKkh5y0SwQ@mail.gmail.com>
Date: Thu, 9 Jan 2020 13:05:22 +0100
Message-ID: <CAF+90c8+19S2j50dD9R8s9cDcphjnoMUPRu8Mw9c8b90rQVAUA@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d0f80c059bb3d37c"
Subject: Re: [PHP-DEV] What to do with "$array[foobar]"?
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000d0f80c059bb3d37c
Content-Type: text/plain; charset="UTF-8"

On Thu, Jan 9, 2020 at 12:12 PM Rowan Tommins <rowan.collins@gmail.com>
wrote:

> On Thu, 9 Jan 2020 at 10:48, Nikita Popov <nikita.ppv@gmail.com> wrote:
>
> > PHP has a couple of legacy string interpolation syntaxes, the most
> > egregious being "$array[foobar]". The issue with this syntax is that the
> > array key is not quoted, is required to be not quoted and is silently
> > accepted.
> >
> > ...
> >
> > What do you think about this? I think my personal preference would be
> > towards phasing out the syntax entirely: If we're going to make people
> > migrate, we can just as well migrate them towards our generic and
> preferred
> > interpolation syntax.
> >
>
>
> Hi Nikita,
>
> I agree that this syntax is peculiar, and think you're right that the most
> consistent way forward is to phase out both "$array[foobar]" and
> "$array[0]".
>
> The biggest problem I see with allowing "$array['foobar']" as an
> alternative spelling is that it makes the inconsistent handling of the bare
> string even more surprising. Consider these pairs:
>

That's true, but I think if the "$array[foobar]" syntax is deprecated in
the same version that "$array['foobar']" is allowed, we can mostly avoid
confusion, because the deprecation message will tell people what's what.

[snip]

My only hesitation is the usual one for language changes: how much working
> code will need to be amended, and how easy is it to identify and correctly
> fix that code?
>
> Since the current syntax isn't ambiguous, it ought in principle to be
> possible for a tool to parse source code and identify and fix instances. I
> think in cases like this, the upgrading notes should link specifically to
> one or more such tools.
>
> Even with such a tool, it's potentially quite a disruptive change, so we
> need to decide how important we think removing this syntax would be.
>

Yes, reliable auto-upgrade should be possible for this change. I'll also do
an analysis run on how common this syntax is in open-source projects later.

Assuming that we do want to phase out the "$array[foobar]" interpolation
syntax, I think a relevant consideration regarding the upgrade-path is
this: Nearly all code-upgrades work by retaining compatibility with the
previous PHP version for a while (for open-source code often a long while),
so effectively the only possible upgrade pass is to go from
"$array[foobar]" to "{$array['foobar']}", as a hypothetical
"$array['foobar']" syntax would not be available in the previous PHP
version.

As such, the question of whether we want to support "$array['foobar']" is
not really relevant to the upgrade path, it can only be answered with
long-term evolution in mind. That is, as an end result, 10 years down the
line, does it make sense for us to support "$array['foobar']" or not? I
think the answer to that may well be "yes", because we already support
"$string" and "$object->prop", so it is in a way natural that
"$array['key']" is also supported, as the last of the "fundamental"
variable syntaxes.

Finally, if we want to leave things alone, we have the option of just
generating a better error message for this.

Regards,
Nikita

--000000000000d0f80c059bb3d37c--