Re^4: [bugs?] perldoc perlre, \G and pos() (why consistency counts)

A very good - "political"- point! 8)

Anyway I didn't say that consistency is more important than functionality!

Let me explain .. if we're talking about rare edge cases any consistent output can be - from a higher point of view - a valid interpration.

An example, lets take a binary operator x which is used on two boole values A and B, such that

X 0 1 B
  - -
0|0 1
1|1 ? 
A
[download]

? denotes the edgecase of A=B=1 - in ikegamis words GI (=garbage input) - which produces inconsistent output, sometimes 0 sometimes 1, which causes many people to avoid this unpredictable operator.

Now surprisingly making it consistent is always a win. With ?=1 we get the OR operator, with ?=0 it's XOR!

Ok it's a simplified example, our case is more complicated, but I hope you get my point, why consistency is -technically - a win.

In our problem ?

Well it's the edge case of resetting pos. The result of the next match is inconsistent for an input of pos=undef and pos=0, which doesn't really make much sense.

So consistency is the first step on the way to kill bugs, your point is more about if improvements should be done step by step!

Cheers Rolf

Comment on Re^4: [bugs?] perldoc perlre, \G and pos() (why consistency counts) Select or Download Code

Replies are listed 'Best First'.
Re^5: [bugs?] perldoc perlre, \G and pos() (why consistency counts) by JavaFan (Canon) on Sep 30, 2009 at 14:19 UTC
Ok it's a simplified example, our case is more complicated, but I hope you get my point, why consistency is -technically - a win. Only from a language user point of view. For instance, in C (and its equivalent in Perl), the result of `i = i++;` is not defined, so it doesn't need to be consistent. This leaves compiler implementors freedom - this freedom may lead to faster code. A more Perlish example is order in which `keys()` return the keys of a hash. Because the order was never defined to be consistent, a security feature (making certain DoS attacks much harder) could have been implemented between 5.8.0 and 5.8.1 (that is, in 2003), instead of having to have 5.10 being a deprecation cycle, and having to wait till 5.12 for an implementation of this fix. Of course, that's on top of the already existing benefit of `keys()` being faster if there's no guaranteed order. Now, I don't want to deny that consistency is usually a good thing. I just don't agree it's always a win.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^5: [bugs?] perldoc perlre, \G and pos() (why consistency counts)
by JavaFan (Canon) on Sep 30, 2009 at 14:19 UTC

Ok it's a simplified example, our case is more complicated, but I hope you get my point, why consistency is -technically - a win.

i = i++;

A more Perlish example is order in which keys() return the keys of a hash. Because the order was never defined to be consistent, a security feature (making certain DoS attacks much harder) could have been implemented between 5.8.0 and 5.8.1 (that is, in 2003), instead of having to have 5.10 being a deprecation cycle, and having to wait till 5.12 for an implementation of this fix. Of course, that's on top of the already existing benefit of keys() being faster if there's no guaranteed order.

Now, I don't want to deny that consistency is usually a good thing. I just don't agree it's always a win.

[reply]
[d/l]
[select]