Re: [Pre-RFC] Scalar object methods (with a working implementation)

On 29 June 2026 23:32:18 BST, Michal Kral <michal@entrylog.eu> wrote: >Hi all, > >Per Seifeddine's suggestion to keep this out of the karma-request thread, I'm opening >a pre-RFC discussion for scalar object methods -- calling a small, curated set of methods directly >on scalar values, e.g. $str->trim(), (3)->pow(2). Hi Michal, Thanks for bringing this to the list. I think it's an interesting experiment, but I agree with a lot of the previous responses that it's just too limited to be useful. The advantage often given for scalar methods is to give us a chance to write a new set of standard utilities that's more consistent and easier to learn. But in order to achieve that, users need to be able to rely on it. With this proposal, there's a long list of requirements: - you need to be running an up to date version of PHP; there's no way to "polyfill" the syntax in userland, or even backport specific methods introduced in later versions - the function you're looking for needs to have a method equivalent in a list that's starting small (again, no polyfills or backports) - you need to understand the requirements for what is allowed as a "receiver", or sprinkle a load of explicit types everywhere just in case - you still need to know what it's called, and what the parameters are If any of those requirements aren't met, you're going to have to fall back on the existing function, which is probably described in several thousand easy to find web pages because it's been in PHP for 30 years. Typed locals is an interesting feature in itself, but comes with a bunch of decisions around things like scope, shadowing, etc, as well as potential performance impact. It deserves an RFC to itself. Even if we add that, encouraging users to write explicit types for every single variable goes against the current trend in other languages, where types are either inferred by default, or can be optionally interred with a keyword like "auto". And while temporary variables can help readability, often they hurt it. Even with some of PHP's uglier function names, I think this... echo htmlspecialchars($_GET['foo']); ..is probably nicer than this string $temp=$_GET['foo']; echo $temp->escapeHtml(); To be honest, I'm not even totally sold on this: echo $_GET['foo']->escapeHtml(); When we could much more simply introduce this: echo \Str\escape_html($_GET['foo']); Rowan Tommins [IMSoP]