in reply to Re^2: [bugs?] perldoc perlre, \G and pos()
in thread [bugs?] perldoc perlre, \G and pos()

It's not that I care so much which result it produces, as long as they are consistent!
I much rather have bugs that produce inconsistent results than consistent results. If it produces consistent results, there will be code that relies on it, and it will (politically) harder to fix the bug. If the results were inconsistent anyway, fixing the bug is very unlikely to break existing code.
  • Comment on Re^3: [bugs?] perldoc perlre, \G and pos()

Replies are listed 'Best First'.
Re^4: [bugs?] perldoc perlre, \G and pos() (why consistency counts)
by LanX (Saint) on Sep 30, 2009 at 12:49 UTC
    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

[reply]
[d/l]
[select]
      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]

In Section Seekers of Perl Wisdom