در تاریخ یکشنبه ۲۰ سپتامبر ۲۰۲۶، ۱۶:۳۸ David Maye Kitenge < [email protected]> نوشت:
> Hey dear. > > (I sent to you an email on Private without realising, I'm sorry for the > duplication). > > It is an interesting proposal. Although I have some issue with the > proposal. > > I'm not an internal contributor, so my opinion doesn't have anything to do > with any RFC approval. > > The str_mask function is something that, for sensitive data, is good for > hiding. That's something done with payment providers such as stripe. > > However, there are many useful functions that, even though useful, aren't > included in an RFC. For example: a slugger/sluggify function. This is the > most important component in CMS and template builders. For example: I'm > creating a modular CMS as Symfony composer dependency. Routing of pages are > dynamic, and require a page path that is a valid in a SEO perspective. > > Would a slugify extension be useful? It would be as useful as a slugify > composer package (to which point I use `uniqid` + a prefix for default > slug, and then I just change it manually). I may create a C extension for > that. However, does it need to be included inside a PHP internal? I don't > think so. No need to. I can create and external package for that, and > Install in every machine or docker image of PHP+ my extension. > > I don't think business logic should be included in a programming language > API. Furthermore, I think it should be as much atomic as possible so that > other developers can build upon it. Look for PHP 8.5 with pipe operator > "|>": this is actually the greatest invention I have seen. It is a very > useful pattern that can be used to rewrite many hard to read program into a > function-like code. Even the str_mark can be created as a function through > it, and it would be perfectly fine. > > From what I read, you don't need str_repeat . . . You can just use "****" > of "XXXX" N times you need. That is something that is very dependent on a > niche use case. I consider ecommerce niche, as not every single web > developer (the purpose of PHP in the first place) are involved in > ecommerce. It's sounds reasonable that PHP is done for developers to get > creative and create their program. That's the reason libraries exist in the > first place. > > What about `uniqid` function, doesn't it look like `str_mark` dilemma? I > don't think so: because creating unique IDs is something very necessary > when you work with databases to ensure that every single object as a unique > identifier. And not only that: I also use it for Server Side Rendering > pages where an HTML component generated by PHP needs an autogenerated id > tag (i.e: a carousel element with a unique identifier for JS code to handle > it dynamically). And both use cases pass from niche to actually useful in > any situation. The fact that you can add entropy is also an important > supplement to the function. This logic also applies to cryptographic > functions, maths function, data structures, SPL, and others. Because it is > not only about use case (which is crucial), it is also about the difficulty > to implement one from scratch, or use a PHP library for it. > > Also, if Cake PHP needed an extension for it, I think they would first > create a composer PHP package, else an extension to it. But creating an > extension to avoid 2-3 function calls sounds excessive, knowing that not > every single project needs to handle PII data (name, SSN, Credit Cards, > etc). Also, when you handle Credit Cards, from what I know, most companies > uses an external a payment provider that mask this information by default > (maybe due to PII norms). So the use for credit card goes automatically > discarded (unless you are a PII compliant payment provider, to which you > still don't need an extension for a function that a PHP class can provide > as a method, in case of Object Mapping classes). > > So, I think it would be quicker and more productive for you to start as an > individual extension, get it very well known, and then by the approval of > several people, get it included later in a PHP RFC. Because I have seen > many small packages and extensions that started as an independent project, > and then included in the main API. > > I also say it because honestly, it is very tiresome to open the mail > Inbox, and read a conversation that goes near 15 threads, in which the > starter of the thread goes back and forth explaining his point with somehow > vague objectives, with some contradictions and stating facts that were not > mentioned at the first place. > > I'm not going against you. It is just that it is not convincing enough to > add it into a main API of a PL. And I'm not saying that it is not useful, > it is just that this can be done easily in many different ways. But I see > your enthusiasm, and I think it would definitely go well if you created, > let's say, an organisation that create useful extension outside the main > API. Because adding such a small function doesn't look useful in a PHP8.* > release page neither. > > I don't want to be rude, I'm sorry if it sounds like it. It just looks > like the conversation about the RFC is going nowhere. > > Thanks for your attention, > David Maye > > El 20/09/2026 13:02 سپهر محمودی <[email protected]> escribió: > > > > > در تاریخ یکشنبه ۲۰ سپتامبر ۲۰۲۶، ۱۳:۵۲ سپهر محمودی <[email protected]> > نوشت: > > > > در تاریخ یکشنبه ۲۰ سپتامبر ۲۰۲۶، ۰۴:۴۳ Pratik Bhujel < > [email protected]> نوشت: > > 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 > > > ---------- > > Hi David, Thanks for sharing your detailed thoughts and perspective! Just to clarify the intent: `str_mask()` is designed not as domain/business logic (like slugification), but as a low-level string manipulation primitive—very similar to existing core primitives like `str_pad()`, `substr_replace()`, and `str_repeat()`. The main reasons for considering it at the core level rather than userland/PECL are: 1. First-class integration with `#[\SensitiveParameter]` to ensure safe handling of sensitive/PII data in stack traces. 2. Providing a strict, fail-closed contract natively without the allocation and performance overhead of composing multiple userland calls. That said, I appreciate your feedback and constructive criticism regarding the mailing list discussion. I've updated the RFC with the latest technical points and benchmarks, and I'll let the RFC process and core voters decide on its inclusion. Thanks again for your time! Best regards, Sepehr
