Re: [rfc] str_mask function

در تاریخ دوشنبه ۲۱ سپتامبر ۲۰۲۶، ۱۶:۴۰ David Maye <david.maye@seigisoft.com> نوشت: > Okay I have another question about the RFC in order to understand it's > well. > > There is no need to use string repeat function at all. If I want five > hashtags, I can just do "#####", and everything is done 👍. > > Because I think people would add the str_repeat function if the data to > mask has a very Dynamic length. But if we're talking about phone numbers, > credit cards, they all have the same predefined length in the entire world > (in the case of phone numbers, some uses 10 digits instead of nine. But > even this can be fixed pretty easily without additional temporary send > string). > > So if you do just like that, you are completely avoiding the use of > intermediate zend string allocation. Just by replacing an operation with > the correct mask, you get exactly the same result we've all needing to > create a new global function. And (if I'm not wrong), if you want to > implement a function called string mask, you can configure it in such way > that it calls substring replace function without an additional Zend string > allocation. > > And thinking about Cake PHP: if they use the kind of pattern that this RFC > that tries to avoid, which is the use of intermediate zend string > allocation just for a temporal buffer, then a pull request for that > function optimization can be done following that kind of pattern (no string > repeat needed) > > Because I think there is no need of very rigorous kind of testing just to > check if some data will leak. No need to have that kind of safeguards > prevents developers from "shooting on their foot" like in the case of > developing in a language like C, just for masking that a a string. > > So my question is: you should use the correct string mask, with predefined > set of characters, inside the substring replace function, then you don't > need to string mask function right? Because the performance is nearly the > same? > > Awesome a 30ms difference for this kind of operation that appears not very > often, is it worth it? Considering the use of unnecessary string repeat? > What the benchmark shows if you just don't use string replace? > > Kind regards, > David Maye. > -------- Hi David, Thank you for bringing this up. It's a great question, and I appreciate the perspective. While it is technically possible to achieve masking using a combination of str_repeat and substr_replace, I believe there are a few reasons why a dedicated str_mask function is valuable for the PHP core: 1. Performance and Intermediate Allocations: Regarding the performance difference: I’ve conducted some benchmarks comparing manual user-land implementations versus the overhead of these operations. You can find the data here: https://gist.github.com/sepehrphpr/86c4be78a3f4882dbd58f6598bb92b16. While a single call might seem negligible, string immutability in PHP means manual masking forces multiple intermediate zend string allocations and creates unnecessary pressure on the Garbage Collector. In high-throughput applications processing millions of strings (e.g., sanitizing logs, PII, or large database result sets), these hidden overheads accumulate rapidly. A C-level implementation bypasses this entirely. 2. Code Clarity and Maintainability: Real-world data is rarely static (e.g., variable-length emails, different phone number formats, or varying credit card lengths). Developers currently have to calculate lengths, handle offsets, and manage concatenation manually. str_mask encapsulates this logic into a single, clean, and expressive call, significantly reducing the surface area for "off-by-one" or logic errors. 3. "Pit of Success": PHP’s philosophy often leans towards providing tools that guide developers toward the "pit of success." Providing a native, optimized, and safe function ensures that developers are using a standardized implementation, rather than relying on inconsistent framework-level helpers or fragile custom code. I’m aiming for this to be a "low-effort, high-impact" utility that prevents reinventing the wheel in every project. Best regards, Sepehr > > > >