Holly > On Jul 11, 2026, at 4:12 AM, Alex Pierstoval Rock <[email protected]> > wrote: > > Le 10/07/2026 à 20:33, Holly Schilling a écrit : >> . >>> As far as scalar methods goes, I hate my implementation. I’m not suggesting >>> someone else could do better, only that the compromises necessary to >>> implement it weren’t worth it. After having implemented it and seen what it >>> demands, I think the right choice is Autoboxing with extensions on the box >>> rather than ever allowing `$this` to not be an object. >>> >>> This is a heated topic lately and I don’t pretend to be an expert. >>> >> Typing this email this morning gave me real hesitation. If I can’t support >> my own implementation, no one else should either. I immediately set out to >> build a better version that I could put my full weight behind. >> >> Autoboxing turned out to be a non-starter as well. The code just didn’t fit >> the model of the code PHP uses. That led me to a diffident path. >> >> C# 14 recently added a new extensions syntax to allow for properties and >> more. When I saw it, I knew it was the right solution. >> >> ``` >> extension string $str { >> function length() { >> return strlen($str); >> } >> } >> >> var_dump(“test”->length()); // int(4) >> ``` >> >> By declaring the parameter inline with the extension declaration, we >> eliminate the downcast of `$this`, the fake accessibility constraints, and >> all the sharp edges the old way introduces. >> >> I immediately rewrote all 3 RFCs to use this new syntax, as well as the code >> to implement it. >> >> Anyone who has been following these discussions, please skim the updated >> docs for changes. > > > Thanks for these changes, they bring better stuff to the table indeed :) > > Still my first thought stands: I think scalar extensions are dispensible, and > having scalars behave "like objects" is quite new to PHP
I have some people saying that scalar methods are a hard requirement. I have others like yourself saying they are a separate issue and should be treated as such. I believe I have struck a good balance here for two reasons. First, they *ARE* a separate RFC that can receive separate voting and discussion. Second, even if they are adopted, there is no mechanism for global pollution. A user only has methods available that they deliberately bring into scope. > workarounds do exist for that: there are quite a few PHP packages to > manipulate strings, utf8 handling, graphemes or codepoints, etc., that could > be used "as string extensions" if such RFC came to become real in the > language. I think it needs more time, investigation on packages, whether to > decide on adding "standard extensions" to start uniformizing string-related > functions (something that's been asked for a long time). This is also something I’m going to push back on. There is nothing that “more time and investigation” will change about how existing libraries will be affected by this. This is an additional tool for them and they will need to find what works best for them once it lands. What Stringy feels works best for them doesn’t have to be what Nette believes works best. That’s the strength of the PHP ecosystem. We create the tools and let people find the best way to use them. The tool is not prescriptive.
