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] > <mailto:[email protected]>> نوشت: > > > > > > > > > > > > در تاریخ یکشنبه ۲۰ سپتامبر ۲۰۲۶، ۰۴:۴۳ Pratik Bhujel > > <[email protected] <mailto:[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 > > > > > > > > > > > > > > > > > > > > > > > >
