Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108545
MIME-Version: 1.0
References: <CACwt+JfMrY7a+uNzgm-2xiMbxvAyB=ME-GBMciufTygFMu4jHQ@mail.gmail.com>
In-Reply-To: <CACwt+JfMrY7a+uNzgm-2xiMbxvAyB=ME-GBMciufTygFMu4jHQ@mail.gmail.com>
Date: Thu, 13 Feb 2020 18:16:19 +0100
Message-ID: <CAOWwgpk6wUuivVY_=8MyXntVQgcqrnMcEghw6mrt9BZqTtZi7g@mail.gmail.com>
To: Patrick ALLAERT <patrickallaert@php.net>
Cc: PHP Development <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000019df50059e784061"
Subject: Re: [PHP-DEV] Re: [RFC] Adding a "Stringable" interface to PHP 8
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--00000000000019df50059e784061
Content-Type: text/plain; charset="UTF-8"

Hi Patrick,

thanks for taking the time to explain your vote.


A virtual "stringable" type (that would be similar to "iterable)" would,
> IMHO, be of a bigger benefit if it is to denote the fact that "a variable
> can be transformed to a string".
> By design, when a variable is declared as "iterable", you know you can
> foreach() on it now, but also on other yet-to-be-implemented concepts that
> would support foreach looping. Think about it as if generators would have
> appeared after "iterable" keyword and then, added to it.
>

I don't make a difference between a type and what you call a virtual type:
any type, virtual or not, is some guarantee that a variable can be used is
some specific way,
typically because some methods exist in the object or something else for
special types managed by the engine.
As such, any type implies a behavior.

My understanding of the existing composite types is that they were added
because PHP lacked union types.
We could imagine a future where PHP will support type aliases. That day,
iterable could be strictly equivalent to
array|Traversable|Iterator|ItratorAggregate and everything would be fine.
PHP doesn't need magic types as a feature of the language to provide any
special behaviors.

Of course, this is my interpretation, and the RFC builds on it.

What is the real advantage of adding this to the core, rather than some
> FIG/PSR standard? This would be compatible in both current versions of PHP
> and next ones at the same time.
>

At least the auto and implicit declaration of the interface + the return
type, that makes a big diff.


>     public string __toString() {
>         throw new \Exception("Foo should not be casted to string, you
> should now...");
>     }
>

This concern exists with any interface actually, nothing specific to this
one.

As the vote is open now, I'm going to keep it going until the end.
If it does not pass - or if it passes and you feel strongly about it, we
might want to submit an RFC on top of course.

Thanks again for your explanation,
Nicolas

--00000000000019df50059e784061--