Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108227
MIME-Version: 1.0
References: <CAOWwgp=STMdOnp9NHn35-mm7TdZD3KKk5PwSGKXeqTyaDBoYHA@mail.gmail.com>
 <CALKiJKoYi3Sjr5Zsj96GVKbp5pX-g4ftw7e3tXk-VB-ufZcXkA@mail.gmail.com>
In-Reply-To: <CALKiJKoYi3Sjr5Zsj96GVKbp5pX-g4ftw7e3tXk-VB-ufZcXkA@mail.gmail.com>
Date: Fri, 24 Jan 2020 16:16:08 +0100
Message-ID: <CAOWwgpnXQrfe_eDthQszxxpTnb=4EpioioHACcbuWagQ7uSZyw@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000675739059ce43de7"
Subject: Re: [PHP-DEV] [RFC] Adding a "Stringable" interface to PHP 8
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000675739059ce43de7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Le mer. 22 janv. 2020 =C3=A0 20:03, Rowan Tommins <rowan.collins@gmail.com>=
 a
=C3=A9crit :

> On Wed, 22 Jan 2020 at 15:47, Nicolas Grekas <nicolas.grekas+php@gmail.co=
m
> >
> wrote:
>
> > Hello everyone,
> >
> > as announced last week, I'm officially opening a discussion for adding =
a
> > "Stringable" interface to PHP 8.
> >
> > The RFC and its rationale are presented here as required:
> > https://wiki.php.net/rfc/stringable
> >
>
>
> I'm still unconvinced on this one, but I was digging into some of the use=
s
> you linked to, to understand why it might be used.
>
> The background to the Symfony Validator one makes for some interesting
> reading: https://github.com/symfony/symfony/pull/31083 and
> https://www.drupal.org/project/drupal/issues/3029540
>
> It seems that Symfony always intended this particular parameter to be a
> string, but couldn't enforce that until PHP 7; Drupal abused it by passin=
g
> in an object, which happens to be stringable but have special behaviour i=
n
> the templating layer, leading to a compatibility break between the two
> projects. In a sense it's just luck that the object in question implement=
s
> __toString(), rather than being a completely unrelated object, since Drup=
al
> relies on it being passed back out unmodified.
>
> Nonetheless, it's an interesting use case, and it's interesting to
> speculate whether it might have been designed how it is anyway without th=
at
> history.



> Ultimately, the contract is that (string)$foo->getMessage() won't
> error, which is ... kind of useful, I guess?
>

Totally, you got it right I think.
Does the RFC trigger any other comments?
Is the patch OK to people that know the engine well?
I'll open the vote on February 6th there are no objections.

Thank you,
Nicolas

--000000000000675739059ce43de7--