ruby-core

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

Thread

Prev Next

In This Thread

Prev Next

[#796] Re: value of assignment (Re: Order of the value of an expression changed? (PR#579)) — Sean Chittenden <sean@...>

[#799] Thread concurrency issue — Elias Karakoulakis <ekarak@...>

[#801] class of $1, $2 in 1.8.0 — dblack@...

[#823] Little Bug in cgi.rb — Florian Frank <flori@...>

[#843] Methods to get at Source References — Brent Roman <brent@...>

[#851] Alternate GC ? — Mathieu Bouchard <matju@...>

[#872] RCR: Add __file__ and __line__ methods to Method and Proc classes — Brent Roman <brent@...>

[#875] OpenSSL for Ruby 0.2.0-pre0 — Michal Rokos <michal@...>

[#883] Re: RCR: Add __file__ and __line__ methods to Method and Proc classes — Brent Roman <brent@...>

[#885] Internal node MEMO (fwd) — Robert Feldt <feldt@...>

[#887] Re: Digest Articles 883-884 (1/1) (ruby-core ML) — Brent Roman <brent@...>

[#889] Bob Jenkins' hashing implementation in Ruby — Mauricio Fern疣dez <batsman.geo@...>

[#890] String and (repost) MemLeak — Michal Rokos <michal@...>

Re: class of $1, $2 in 1.8.0

Thread

In This Thread

[#872] RCR: Add file and line methods to Method and Proc classes — Brent Roman <brent@...>

[#883] Re: RCR: Add file and line methods to Method and Proc classes — Brent Roman <brent@...>