Re: [PHP-DEV] [RFC] Adding a "Stringable" interface to PHP 8

This is only part of a thread. view whole thread
  108258
January 27, 2020 09:19 nikita.ppv@gmail.com (Nikita Popov)
On Wed, Jan 22, 2020 at 4:47 PM Nicolas Grekas grekas+php@gmail.com>
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 > > The patch is found on GitHub, where some discussions happened already, you > might be interested in having a look: > https://github.com/php/php-src/pull/5083 > > TL;DR, I think we need an interface to allow passing objects with a > __toString() method in a type-safe way, using the string|Stringable type. > Here is the stub of the proposal: > interface Stringable { public function __toString(): string; } > > I invite everyone to review the RFC before commenting here as I tried to > sum up considerations that some already had before and that you might have > too. > > Cheers, > Nicolas >
I'm wondering whether it could make sense to automatically implement this interface for all classes that define __toString(). Explicitly implementing the interface is useful for the transition period (where old PHP versions also need to be supported), but when considering only PHP 8 support, I think it may make sense to implicitly implement the interface. If the __toString() functionality also works fine without implementing the interface, and there's probably only going to be relatively few consumers of the Stringable type, it will likely be quite common that the interface will not get implemented... Automatically implementing interfaces based on implemented methods could also be a general language feature (see Go interfaces for example), but likely not one we're interested in having in it's full generality. In this particular case, it seems useful though. Regards, Nikita
  108260
January 27, 2020 09:29 nicolas.grekas+php@gmail.com (Nicolas Grekas)
Le lun. 27 janv. 2020 à 10:19, Nikita Popov ppv@gmail.com> a écrit :

> On Wed, Jan 22, 2020 at 4:47 PM Nicolas Grekas < > nicolas.grekas+php@gmail.com> 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 >> >> The patch is found on GitHub, where some discussions happened already, you >> might be interested in having a look: >> https://github.com/php/php-src/pull/5083 >> >> TL;DR, I think we need an interface to allow passing objects with a >> __toString() method in a type-safe way, using the string|Stringable type.. >> Here is the stub of the proposal: >> interface Stringable { public function __toString(): string; } >> >> I invite everyone to review the RFC before commenting here as I tried to >> sum up considerations that some already had before and that you might have >> too. >> >> Cheers, >> Nicolas >> > > I'm wondering whether it could make sense to automatically implement this > interface for all classes that define __toString(). Explicitly implementing > the interface is useful for the transition period (where old PHP versions > also need to be supported), but when considering only PHP 8 support, I > think it may make sense to implicitly implement the interface. If the > __toString() functionality also works fine without implementing the > interface, and there's probably only going to be relatively few consumers > of the Stringable type, it will likely be quite common that the interface > will not get implemented... > > Automatically implementing interfaces based on implemented methods could > also be a general language feature (see Go interfaces for example), but > likely not one we're interested in having in it's full generality. In this > particular case, it seems useful though. >
This looks like a nice improvement to the proposal, it'd be OK on my side. For the implementation, I might need your help to implement this logic, especially for extensions, since I suppose we'd like them to also have this behavior of implicitly declaring the return-type + interface when they declare the method. Could you please help me achieve that? Nicolas
  108273
January 27, 2020 15:55 larry@garfieldtech.com ("Larry Garfield")
On Mon, Jan 27, 2020, at 10:19 AM, Nikita Popov wrote:
> On Wed, Jan 22, 2020 at 4:47 PM Nicolas Grekas grekas+php@gmail.com> > 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 > > > > The patch is found on GitHub, where some discussions happened already, you > > might be interested in having a look: > > https://github.com/php/php-src/pull/5083 > > > > TL;DR, I think we need an interface to allow passing objects with a > > __toString() method in a type-safe way, using the string|Stringable type. > > Here is the stub of the proposal: > > interface Stringable { public function __toString(): string; } > > > > I invite everyone to review the RFC before commenting here as I tried to > > sum up considerations that some already had before and that you might have > > too. > > > > Cheers, > > Nicolas > > > > I'm wondering whether it could make sense to automatically implement this > interface for all classes that define __toString(). Explicitly implementing > the interface is useful for the transition period (where old PHP versions > also need to be supported), but when considering only PHP 8 support, I > think it may make sense to implicitly implement the interface. If the > __toString() functionality also works fine without implementing the > interface, and there's probably only going to be relatively few consumers > of the Stringable type, it will likely be quite common that the interface > will not get implemented... > > Automatically implementing interfaces based on implemented methods could > also be a general language feature (see Go interfaces for example), but > likely not one we're interested in having in it's full generality. In this > particular case, it seems useful though. > > Regards, > Nikita
I believe Anthony Ferrara proposed "Weak interfaces" once many years ago, which is essentially what you're describing. It didn't get much traction although I'm unclear why. (Possibly just less familiarity with Go at the time?) I agree not all interfaces should be implicit, but having implicitly-implementable interfaces does sound generally useful. That shouldn't block this RFC, but might this RFC be a model for how to implement such things more generically in the future? --Larry Garfield
  108277
January 27, 2020 19:20 mike@newclarity.net (Mike Schinkel)
> On Jan 27, 2020, at 10:55 AM, Larry Garfield <larry@garfieldtech.com> wrote: > > On Mon, Jan 27, 2020, at 10:19 AM, Nikita Popov wrote: >> Automatically implementing interfaces based on implemented methods could >> also be a general language feature (see Go interfaces for example), but >> likely not one we're interested in having in it's full generality. In this >> particular case, it seems useful though. >> >> Regards, >> Nikita > > I believe Anthony Ferrara proposed "Weak interfaces" once many years ago, which is essentially what you're describing. It didn't get much traction although I'm unclear why. (Possibly just less familiarity with Go at the time?) > > I agree not all interfaces should be implicit, but having implicitly-implementable interfaces does sound generally useful. That shouldn't block this RFC, but might this RFC be a model for how to implement such things more generically in the future? > > --Larry Garfield
Glad to see you picked up on this Larry. I don't think "Weak Interfaces" became an RFC unless Google is failing me, but I found a reference to it being on the mailing list from Matthieu Napoli's article on GitHub about decoupling, which is worth a read: https://github.com/mnapoli/mnapoli.github.io/blob/master/articles/decoupling-packages.md As far as Go's implicit interfaces, I have found that to be one of the most compelling language features of Go, and would be ecstatic if we could find a way to support implicit interfaces in PHP. -Mike
  108452
February 11, 2020 08:56 nicolas.grekas+php@gmail.com (Nicolas Grekas)
Le lun. 27 janv. 2020 à 10:19, Nikita Popov ppv@gmail.com> a écrit :

> On Wed, Jan 22, 2020 at 4:47 PM Nicolas Grekas < > nicolas.grekas+php@gmail.com> 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 >> >> The patch is found on GitHub, where some discussions happened already, you >> might be interested in having a look: >> https://github.com/php/php-src/pull/5083 >> >> TL;DR, I think we need an interface to allow passing objects with a >> __toString() method in a type-safe way, using the string|Stringable type.. >> Here is the stub of the proposal: >> interface Stringable { public function __toString(): string; } >> >> I invite everyone to review the RFC before commenting here as I tried to >> sum up considerations that some already had before and that you might have >> too. >> >> Cheers, >> Nicolas >> > > I'm wondering whether it could make sense to automatically implement this > interface for all classes that define __toString(). Explicitly implementing > the interface is useful for the transition period (where old PHP versions > also need to be supported), but when considering only PHP 8 support, I > think it may make sense to implicitly implement the interface. If the > __toString() functionality also works fine without implementing the > interface, and there's probably only going to be relatively few consumers > of the Stringable type, it will likely be quite common that the interface > will not get implemented... >
This proposal has been implemented by Nikita himself on the linked PR, see 2nd commit: https://github.com/php/php-src/pull/5083 I updated the RFC accordingly: https://wiki.php.net/rfc/stringable I think the RFC is ready for entering the voting stage. Any other comments before? Cheers, Nicolas
  108465
February 11, 2020 11:58 nikita.ppv@gmail.com (Nikita Popov)
On Tue, Feb 11, 2020 at 9:57 AM Nicolas Grekas grekas+php@gmail.com>
wrote:

> Le lun. 27 janv. 2020 à 10:19, Nikita Popov ppv@gmail.com> a > écrit : > > > On Wed, Jan 22, 2020 at 4:47 PM Nicolas Grekas < > > nicolas.grekas+php@gmail.com> 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 > >> > >> The patch is found on GitHub, where some discussions happened already, > you > >> might be interested in having a look: > >> https://github.com/php/php-src/pull/5083 > >> > >> TL;DR, I think we need an interface to allow passing objects with a > >> __toString() method in a type-safe way, using the string|Stringable > type. > >> Here is the stub of the proposal: > >> interface Stringable { public function __toString(): string; } > >> > >> I invite everyone to review the RFC before commenting here as I tried to > >> sum up considerations that some already had before and that you might > have > >> too. > >> > >> Cheers, > >> Nicolas > >> > > > > I'm wondering whether it could make sense to automatically implement this > > interface for all classes that define __toString(). Explicitly > implementing > > the interface is useful for the transition period (where old PHP versions > > also need to be supported), but when considering only PHP 8 support, I > > think it may make sense to implicitly implement the interface. If the > > __toString() functionality also works fine without implementing the > > interface, and there's probably only going to be relatively few consumers > > of the Stringable type, it will likely be quite common that the interface > > will not get implemented... > > > > > This proposal has been implemented by Nikita himself on the linked PR, see > 2nd commit: > https://github.com/php/php-src/pull/5083 > > I updated the RFC accordingly: > https://wiki.php.net/rfc/stringable > > I think the RFC is ready for entering the voting stage. > Any other comments before? >
Just so someone has mentioned it... is "Stringable" really the best name for this interface? Reddit really didn't like it ;) Some possible alternatives: ToString, HasToString, CastsToString. Something to keep in mind is that there has been a recent proposal for "Arrayable" as well, and that had very different semantics (not about __toArray() at all). Regards, Nikita
  108467
February 11, 2020 12:10 norbert@aimeos.com (Aimeos | Norbert Sendetzky)
Am 11.02.20 um 12:58 schrieb Nikita Popov:
> Just so someone has mentioned it... is "Stringable" really the best name > for this interface? Reddit really didn't like it ;) Some possible > alternatives: ToString, HasToString, CastsToString.
I would vote for "Stringable" because PHP already has interfaces like Throwable, Countable, Traversable, Serializable and so on :-)
> Something to keep in mind is that there has been a recent proposal for > "Arrayable" as well, and that had very different semantics (not about > __toArray() at all).
I came up with the proposal of an Arrayable interface whose intention is in fact very close to Stringable (can be used like an array and converted to array vs. can be converted to string) But time doesn't seem to be ripe for Arrayable because the __toArray() RFC isn't accepted yet and there needs to be more discussion if Arrayable should only contain __toArray() or if it should extend from Countable and Traversable too.
  108468
February 11, 2020 12:12 nicolas.grekas+php@gmail.com (Nicolas Grekas)
> > Just so someone has mentioned it... is "Stringable" really the best name > for this interface? Reddit really didn't like it ;) Some possible > alternatives: ToString, HasToString, CastsToString. >
Naming things... I'm not sure reddit is the way to lobby php-internals... I proposed Stringable because it is the most consistent to me: Traversable, Serializable, Countable, Throwable, JsonSerializable all are related to some special engine behavior, which this ones also is. I'm on the side of keeping Stringable.
> Something to keep in mind is that there has been a recent proposal for > "Arrayable" as well, and that had very different semantics (not about > __toArray() at all) >
I didn't take part on this discussion, but I'm totally on Marco's side on this one, I really hope this will NOT make it into the engine, for the reasons he gives... :) Nicolas
  108475
February 11, 2020 12:58 guilliam.xavier@gmail.com (Guilliam Xavier)
On Tue, Feb 11, 2020 at 1:12 PM Nicolas Grekas
grekas+php@gmail.com> wrote:
> > > > > Just so someone has mentioned it... is "Stringable" really the best name > > for this interface? Reddit really didn't like it ;) Some possible > > alternatives: ToString, HasToString, CastsToString. > > > > Naming things... > I'm not sure reddit is the way to lobby php-internals... > I proposed Stringable because it is the most consistent to me: > Traversable, Serializable, Countable, Throwable, JsonSerializable > all are related to some special engine behavior, which this ones also is.
But one could argue that "string" is not a verb like "traverse", "serialize", "count", "throw" etc. Potential alternatives would be Stringifyable (or Stringifiable?), StringCastable, StringConvertible... (Even though I personally have no problem with "Stringable") -- Guilliam Xavier
  108477
February 11, 2020 13:11 michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)
wt., 11 lut 2020 o 13:59 Guilliam Xavier xavier@gmail.com>
napisał(a):

> On Tue, Feb 11, 2020 at 1:12 PM Nicolas Grekas > grekas+php@gmail.com> wrote: > > > > > > > > Just so someone has mentioned it... is "Stringable" really the best > name > > > for this interface? Reddit really didn't like it ;) Some possible > > > alternatives: ToString, HasToString, CastsToString. > > > > > > > Naming things... > > I'm not sure reddit is the way to lobby php-internals... > > I proposed Stringable because it is the most consistent to me: > > Traversable, Serializable, Countable, Throwable, JsonSerializable > > all are related to some special engine behavior, which this ones also is. > > But one could argue that "string" is not a verb like "traverse", > "serialize", "count", "throw" etc. > Potential alternatives would be Stringifyable (or Stringifiable?), > StringCastable, StringConvertible... > (Even though I personally have no problem with "Stringable") > > Maybe StringObject? We do already have ArrayObject.
BR, -- Michał Brzuchalski
  108478
February 11, 2020 13:13 guilliam.xavier@gmail.com (Guilliam Xavier)
On Tue, Feb 11, 2020 at 2:11 PM Michał Brzuchalski
brzuchalski@gmail.com> wrote:
> > wt., 11 lut 2020 o 13:59 Guilliam Xavier xavier@gmail.com> napisał(a): >> >> On Tue, Feb 11, 2020 at 1:12 PM Nicolas Grekas >> grekas+php@gmail.com> wrote: >> > >> > > >> > > Just so someone has mentioned it... is "Stringable" really the best name >> > > for this interface? Reddit really didn't like it ;) Some possible >> > > alternatives: ToString, HasToString, CastsToString. >> > > >> > >> > Naming things... >> > I'm not sure reddit is the way to lobby php-internals... >> > I proposed Stringable because it is the most consistent to me: >> > Traversable, Serializable, Countable, Throwable, JsonSerializable >> > all are related to some special engine behavior, which this ones also is. >> >> But one could argue that "string" is not a verb like "traverse", >> "serialize", "count", "throw" etc. >> Potential alternatives would be Stringifyable (or Stringifiable?), >> StringCastable, StringConvertible... >> (Even though I personally have no problem with "Stringable") >> > > Maybe StringObject? We do already have ArrayObject.
But ArrayObject is not a interface (ArrayAccess is). -- Guilliam Xavier
  108481
February 11, 2020 13:20 norbert@aimeos.com (Aimeos | Norbert Sendetzky)
Am 11.02.20 um 14:11 schrieb Michał Brzuchalski:
>>> Traversable, Serializable, Countable, Throwable, JsonSerializable >>> all are related to some special engine behavior, which this ones also is. >> >> But one could argue that "string" is not a verb like "traverse", >> "serialize", "count", "throw" etc. >> Potential alternatives would be Stringifyable (or Stringifiable?), >> StringCastable, StringConvertible... >> (Even though I personally have no problem with "Stringable") >> > Maybe StringObject? We do already have ArrayObject.
A StringObject would need to offer the same methods that are available for strings (even if ArrayObject doesn't do that completely). Even if "string" isn't a verb, it matches the intended meaning: serialize -> Serializeable -> can be serialized count -> Countable -> can be counted throw -> Throwable -> can be thrown If I take the alternatives into account, I would still opt for "Stringable" because it's: - easy to spell - easy to remember - shorter than the alternatives - matches exactly the intended meaning - consistent with the other PHP class nameings
  108482
February 11, 2020 14:13 ben@benramsey.com (Ben Ramsey)
> On Feb 11, 2020, at 07:20, Aimeos | Norbert Sendetzky <norbert@aimeos.com> wrote: > > Am 11.02.20 um 14:11 schrieb Michał Brzuchalski: >>>> Traversable, Serializable, Countable, Throwable, JsonSerializable >>>> all are related to some special engine behavior, which this ones also is. >>> >>> But one could argue that "string" is not a verb like "traverse", >>> "serialize", "count", "throw" etc. >>> Potential alternatives would be Stringifyable (or Stringifiable?), >>> StringCastable, StringConvertible... >>> (Even though I personally have no problem with "Stringable") >>> >> Maybe StringObject? We do already have ArrayObject. > > A StringObject would need to offer the same methods that are available > for strings (even if ArrayObject doesn't do that completely). > > Even if "string" isn't a verb, it matches the intended meaning: > serialize -> Serializeable -> can be serialized > count -> Countable -> can be counted > throw -> Throwable -> can be thrown > > If I take the alternatives into account, I would still opt for > "Stringable" because it's: > - easy to spell > - easy to remember > - shorter than the alternatives > - matches exactly the intended meaning > - consistent with the other PHP class nameings
In English, pretty much any noun can be used as a verb. Also, string does have a verb form. It can mean “to thread on or as if on a string” or “to put together (words, ideas, etc.) like objects threaded on a string” or “to form into strings.” In computing, a string is a series of characters that have been strung together. https://www.merriam-webster.com/dictionary/string :-) Cheers, Ben