On Fri, Sep 25, 2026, at 5:43 AM, Gina P. Banyard wrote:
> On Friday, 25 September 2026 at 07:59, Sjoerd Langkemper
> <[email protected]> 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
