Re: [rfc] str_mask function

From: Date: Sun, 20 Sep 2026 11:02:37 +0000
Subject: Re: [rfc] str_mask function
References: 1 2 3 4 5 6 7 8  Groups: php.internals 
Request: Send a blank email to internals+get-132560@lists.php.net to get a copy of this message
در تاریخ یکشنبه ۲۰ سپتامبر ۲۰۲۶، ۱۳:۵۲ سپهر محمودی <sepehrphpr@gmail.com> نوشت: > > > در تاریخ یکشنبه ۲۰ سپتامبر ۲۰۲۶، ۰۴:۴۳ Pratik Bhujel < > prateekbhujelpb@gmail.com> نوشت: > >> Hi Sepehr, >> >> Thanks. I think we may be talking past each other slightly. >> >> When I see major frameworks like CakePHP having to implement custom >> utility functions for simple tasks like string masking, it suggests that we >> are reinventing the wheel. >> >> That shows that masking is a real use case, which I don’t dispute. What >> I’m still missing is evidence that this *specific primitive* is what >> those projects are repeatedly reinventing. >> >> If CakePHP is part of the motivation, I think the strongest evidence >> would be to show an actual CakePHP implementation/use case that could be >> replaced by: >> >> str_mask(string, mask_char, offset, length) >> >> without changing its semantics. Even better would be a small prior-art >> section with several independent libraries/frameworks converging on roughly >> the same operation. >> >> Otherwise, “frameworks implement masking” establishes the problem, but >> not necessarily this particular API as the abstraction PHP core should >> standardize. >> >> The evidence for my point is available in my RFC. >> >> I did read it. My concern is exactly the distinction above: evidence that >> masking exists is different from evidence that this API is the common >> missing primitive. >> >> Assuming the recent semantic issues have now been addressed, this is the >> part I would focus on before implementation-level optimization. A concrete >> before/after from the cited real-world code would make the case much easier >> to evaluate. >> >> Best regards, >> Pratik Bhujel >> >> ---------- >> > Hey Pratik, Regarding the evidence for common usage: I've actually included a direct comparison and link in the RFC's "Motivation / Prior Art" section at the very end. It demonstrates how existing code patterns directly map to the proposed str_mask() signature. Would be great if you could glance over it when you have a moment. Let me know if that addresses your point! Best, Sepehr >

« previous php.internals (#132560) next »