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
>