On Sat, 8 Feb 2003 06:52:17 +0900
dblack / candle.superlink.net wrote:

<snip>
> > > changing the semantics of well-known methods in subclasses) than
> > > for backing out this change.
> 
> There's no way to define "well-known" robustly in that context,
> though.  Also, even if the semantics weren't changed (I assume you
> mean the argument count), presumably the overridden version would do
> something different from the String version, so this 1.8.0 shift would
> still have an impact.
<snip>

I would bring up some points here:

  *  There shouldn't be a reason to define "well-known"... as a
     general principle, semantics should either 1) not change,
     2) extend only, or 3) the error is correct behavior.  That is:

        1)  Changing semantics is questionable whether you're a fan
            of "duck typing" or not: changing semantics means your
            duck doesn't quack anymore.

        2)  New semantics can be appended to the old ones:

              def to_i(number = nil); ... end

        3)  If your semantics _do_ change, the error is actually
            correct by definition: you're trying to do something
            that's not allowed.  I'll bring up the Circle < Ellipse
            example here; if you change the semantics of
            Circle#setRadius to accept either (x, y; where x == y) or
            (x), then there _is_ an error when you use (x, y; x != y).

            Code should be smarter and take errors like this in
            stride.

  *  This example isn't complete, and seems slightly contrived to
     me... the code in question should be aware at the point of code
     that the behavior is different.  What does the to_i parameter do?
     (Radix? You can default that. ;)

  *  Changing a method to do something illogical is possible but
     questionable.  That is, you could make MyString#to_i print the
     string with a formatting parameter, but why would you do this?
     Conventions are a _good_ thing... breaking them limits
     predictability, which defeats the point of code in the first
     place.

-- 
Ryan Pavlik <rpav / users.sf.net>

"Are there no depths that you won't sink to?
 - We won't know 'till we get there!" - 8BT