Front page | perl.perl5.porters |
Postings from August 2010
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. > 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. 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. -- Paul "LeoNerd" Evans leonerd@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/Thread Previous | Thread Next