develooper Front page | perl.perl5.porters | Postings from August 2010

Re: qr stringification: why are xism always present? I'm worriedabout backward compatibility

Thread Previous | Thread Next
karl williamson
August 7, 2010 07:22
Re: qr stringification: why are xism always present? I'm worriedabout backward compatibility
Message ID:
Ben Morrow wrote:
> Quoth (Aristotle Pagaltzis):
>> * karl williamson <> [2010-08-05 19:25]:
>>> Aristotle Pagaltzis wrote:
>>>> * karl williamson <> [2010-08-04 15:40]:
>>>>> FWIW, I have given this some thought, and came to the
>>>>> conclusion that Perl is almost certainly never going to
>>>>> change the defaults, because of the backward compatibility
>>>>> issues.
>>>> Yet you *are* changing the past default right now, *in spite*
>>>> of back compat issues… :-)
>>> I'm not sure I understand. The default options remain the same.
>>> Ben made the point in your quote above that by doing this now
>>> when we are pretty much agreed that something should be done
>>> will cause this to likely be the last time adding a flag would
>>> cause backward compatibility issues.
>> If the default is not allowed to change again, then we gain
>> nothing from `(?~:)`.
> Right.
>> Right now, the problem is that the default is changing, such that
>> `(?-xism)` is not an accurate representation of it.
> Right.
>> This is caused by the fact that we are introducing a flag that
>> *requires* a choice of default.
>> What happens if we run into this situation again in the future?
>> If the meaning of `(?~:)` is not allowed to change, then it will
>> no longer be an accurate representation, so patterns will have to
>> stringify to `(?~Xy:)`.
> Wrong. (?~:), with no further flags, means 'The default, whatever that
> happens to be in this version of perl'. If we later introduce flags Xy,
> Xz and Xw such that one of these must be specified, and Xy is the
> default, then (?~:) with no mention of any X* flag will imply Xy. Thus
> in
>     /foo(?~:bar)baz/Xz
> 'bar' will be matched with /Xy in effect, rather than /Xz.
> (As a separate issue, presumably /Xy in such a case would correspond to
> the current semantics, or a bug-fixed version thereof, with /Xz and /Xw
> invoking new semantics.)
>> (Personally I would rather skip the entire discussion and train
>> people to do
>>     ( my $re_defaults = "" . qr/ / ) =~ s/ //g;
>> and use *that* instead of hardcoding *either* `(?-xism:)` *or*
>> `(?~:)` *or* anything else, because that’s guaranteed to yield
>> the right default stringification now and forever.)
> +1. I'm beginning to regret suggesting the idea in the first place...
> Ben

I guess I'll drop this too, as I'm apparently the last person who thinks 
it is a good idea.  The problem with I see in Aristotle's suggestion is 
that how do people get trained?  It's not an obvious solution or we 
wouldn't have the various cases where things break.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About