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

Re: RFC: New regex modifier flags

Thread Previous | Thread Next
karl williamson
August 3, 2010 17:02
Re: RFC: New regex modifier flags
Message ID:
Paul LeoNerd Evans wrote:
> On Tue, Aug 03, 2010 at 01:22:36PM -0600, karl williamson wrote:
>> I think that's it.  Here is your ballot (I briefly what I think are
>> the up/downsides.  Feel free to add things.)
> Will this be first-past-the-post, or AV? ;)
> My votes in preference, are:
>> 2) Use two-letter options for the mutually exclusive ones.
>> Extensible, visually distinguishable, but /abc/Clip may be hard to
>> read.
> Most preferred. We've suddenly now bought ourselves precident to have a
> great number of other switches and knobs in future, should we find we
> require them.
>> 3) Use single capital letters for these options; distinguishable,
>> not extensible.
> 2nd choice. A lesser version of the above.

I want to be clear about this.  By not extensible, I mean that this 
option implies that capital letter options would not be usable for 
anything else but specifying character set semantics.
>> 5) Use single letter lower case option letters, but until 5.16 they
>> are only valid in the (?:) form.  They are not visibly distinguished
>> from options that aren't mutually exclusive.
> 3rd choice. This might not be so bad as their effect is quite locallised
> anyway, so
>   (?u:\d)   matches a unicode digit
> is fairly neat and a resonable way to access the functionallity.
> Though, I somewhat dislike either this or 6); see below.
>> 6) Use single letter lower case option letters implemented in such a
>> way that until 5.16 ambiguities are resolved to the existing
>> interpretations.  The option letters are not visibly distinguished
>> from options that aren't mutually exclusive.  After the deprecation
>> cycle in 5.14, there won't be these ambiguities.  My vote goes to
>> this one.
> 4th choice. Introducing new flags only to then change their behaviour in
> short time seems a bit unpredictable.

And let me make sure this is clear.  Option 6) is a superset of option 
5.  And code written that would work in 5.14 would continue to work 
after that.  But in 5.14, you would have to order the suffix-style 
modifiers so that they don't spell an existing keyword.  For example, 
you would have to say /abc/el instead of /abc/le.  The first form would 
be valid in 5.14; both forms in 5.16.  And of course, (?u:\d) would work 
under this option as well as option 5).

> Also, this and 5) both suffer, in that the mutually-exclusive choice for
> the Unicode behaviour should not feel the same as all the current flags,
> which are currently orthogonal to each other. Not a -major- problem; to
> pick UNIX precident again, we do note that tar -xc are mutually
> exclusive but tar -xzv is fine. A little messy but I could live with it.
>> 1) Do nothing.  Don't implement this, leave the Unicode bugs there.
> 5th choice. We do need some Unicode support here, but if we can't think
> of a decent way to implement it now, we may want to consider further
> thought until a better idea avails itself.
>> 4) Use single letter lower case option letters, but choose
>> non-mnemonic ones to avoid ambiguities with existing keywords.  They
>> are not visibly distinguished from options that aren't mutually
>> exclusive.
> Last choice. It'd be worse to introduce a poor interface given all the
> better ideas that might fit, simply for the expedience of getting a
> quick bug fix out now.

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