در تاریخ شنبه ۱۹ سپتامبر ۲۰۲۶، ۱۵:۲۰ Pratik Bhujel < [email protected]> نوشت:
> Hi Sepehr, > > I don’t think benchmarks actually answer the main objection being raised > here. They can show that a dedicated C implementation is faster than > composing substr_replace() and str_repeat(), but they cannot show that > this operation deserves a permanent core API. > > Before optimizing it, I’d rather see evidence that the abstraction itself > is common: for example, a corpus analysis of real PHP > applications/frameworks showing how often this exact offset/length masking > pattern occurs and what existing implementations look like. Otherwise we > may just be benchmarking a convenience wrapper. > > Also, the current RFC still documents out-of-bounds offsets as returning > the original string unchanged, despite your reply saying it was changed to > fail-closed, and it still says a multi-byte $mask_char is silently > reduced to its first byte. Those semantics should probably be made > consistent first. > > And Jordi’s #[SensitiveParameter] point seems especially relevant if > handling sensitive data is the primary motivation. > > So I think the order should be: demonstrate the use-case, settle the > contract, then benchmark the implementation. > > Best regards, > Pratik Bhujel > ----------- Hi Pratik, Thank you for your feedback and for taking the time to review my proposal. You make some very valid points regarding optimization. I completely agree with you that performance within the PHP core is critical and must meet the highest standards. My main motivation for this RFC is to address a practical need in real-world scenarios. 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. Standardizing this capability within the PHP core would be a significant benefit to the entire ecosystem. I would be very happy to hear your specific thoughts on the implementation. If you have any suggestions on how I can improve the proposal or address your concerns, I am very open to that discussion. The evidence for my point is available in my RFC. Looking forward to hearing from you. Best regards, Sepehr
