On 02/21/2011 10:59 AM, Abigail wrote:
> On Mon, Feb 21, 2011 at 10:49:31AM -0700, Tom Christiansen wrote:
>>>> Here are the ones I can think of at the moment:
>>>>
>>>> /w to change the meaning of \b to Unicode's word boundary algorithm.
>>>> /k to change /i to mean compatible decomposition
>>
>>> Please don't use /k. Having /k means '(?k:)' becoming valid, and that
>>> will interfere with Regexp::Common, which uses '(?k:)'. /p started out
>>> as /k, and it was changed to /p as to not interfere with Regexp::Common.
>>
>> The first thing that comes to mind is: do you have an alternate suggestion?
>>
>> As for Regexp::Common, UGH! I have rather mixed feelings about that.
>>
>> It's not even a module in the core Perl distribution, and yet its use of a
>> syntax reserved to the core blocks progress in that direction. How many
>> others like this exist?
>>
>> On the other hand, adding /k would suddenly change the behavior of
>> existing programs through no fault of their owners. As frustrating
>> though this may me, it seems a real blocker, and I fear you're right.
>
> It's not going to change meaning of existing programs.
>
> But what Regexp::Common does is take a string, process it for '(?k:)',
> and turn it into a pattern. When Damian picked '(?k:)', it was safe,
> as it didn't have a meaning. By allowing it, one creates an ambiguity:
> does the user intent the Regexp::Common meaning of '(?k:)', or the
> regexp engines meaning?
>
>> But it is a very natural thing to use.
>
> And so it was for ${^POSTMATCH} and friends before it got renamed to /p.
>
>
>
> I'm not saying /k should not be used. But people should be aware of the
> implications.
>
>
> Abigail
>
I temporarily forgot about /k's existing use, but it is in the code
comments. So we need to have a compelling reason to appropriate it.
Thread Previous
|
Thread Next