Front page | perl.perl5.porters |
Postings from August 2010
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