Re: Pre-RFC: adding a Regex\CompiledRegex class for compiling regular expressions

On Fri, Sep 25, 2026, at 5:43 AM, Gina P. Banyard wrote: > On Friday, 25 September 2026 at 07:59, Sjoerd Langkemper > <sjoerd-php@linuxonly.nl> wrote: >> On Wed, Sep 23, 2026, at 21:01, Gina P. Banyard wrote: >>> This class could lay the foundation on which to build a new nice OO API >> >> Nice. I am in favor of improving the API, instead of slapping more flags onto the existing >> one. I also like the idea of an OOP Regex API. Though I would ask that we just call it Regex, not CompiledRegex. The "Compiled" adds no relevant information that a developer cares about, but doubles the length of text they need to read and begs the question of how to make an "uncompiled regex" (which is not a thing). >>> returning a bool type >> >> Would it make more sense to return a Match object, with captured groups? > > How would this Match object work? What is it's API? And if you don't > care about captured groups why would you need to instantiate an (or > multiple) object when a boolean value would do just fine. > That's why I said I don't want to spend time on designing an API as > this frankly needs multiple methods and is going to be complicated. > There are also new PCRE2 features not exposed to userland where it may > make sense to do so in a greenfield API. That feels like two separate methods then. match(): bool and matchCapture(): MatchResult, or something like that. >> The proposed API would result in calls like this: >> new CompiledRegex(".*", false, false, false, true, true, true, false, true) >> where it is hard to determine what all the true/false parameters mean. Would it be better >> to pass enums instead? Or is this solved by editor hints nowadays > > Arguably we have named parameters to just toggle the options that are > different from the default, so I wouldn't be writing a call to it like > this nowadays anyway. > But Nora did suggest an array of enum RegexOptions on the PR, > and my > reply was that if PHP had a way to pass an Enum set this would be the > best approach as you'd only have one parameter. > In any case I don't have strong feelings about this part (or maybe I > should spend some time and figure out a way to make enum sets a reality > before) If we can make sets a native type with good operator usage (I have designs for this), then enum sets would fall out naturally. Baring that, I assumed this would always be called with sparse named arguments, which I am fine with. (As someone who rarely uses regexes, admittedly.) --Larry Garfield