Not a solution to your problem but I just want to point out that the
correct way to write regex tests is
is($re, qr/what I expected/);
and that this will never be upset by changes like demerphq is describing,
F
On 03/08/07, demerphq <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I thought id bring a tricky subject that ive encountered in Perl core
> development up here so you testing mavens can have a look at the
> problem and maybe come up some suggestions for me.
>
> The problem is this: one of the main obstacles for adding new regex
> flags to the perl regex engine are the oodles of tests that expect
> stringified regular expressions to look like:
>
> /\A\(\?[msix-]*:.*\)\z/s
>
> There are also lots of tests out there that do thing like:
>
> is("$qr","(?ms-ix:...)",'Got back the regex we expected');
>
> all of these break if I add a new modifier or change the flag layout
> in any way (it was surprising how many test failures were caused by
> reordering the flags). With Perl 5.9.4 or so there is a new modifier
> 'p' (for 'preserve') but various special properties of what it
> represents mean I was able to bypass the problem as it only shows up
> in the list if its on, there is no 'off' form of it. However for a
> true boolean flag this wont work.
>
> So assuming we want to add new modifiers (we kinda do) how should this
> be addressed? Both going forward and dealing with legacy code.
>
> BTW I recall that a notable area in the core which does this type of
> naughty testing is actually the Test:: modules themselves. :-)
>
> Im open to suggestions that dont involve hunting down all of these
> naughty tests and fixing them. Including stuff that doesnt strictly
> involve test modules.
>
> Cheers,
> Yves
>
>
> --
> perl -Mre=debug -e "/just|another|perl|hacker/"
>
