ruby-core

On Sat, 8 Feb 2003 08:15:08 +0900
dblack@candle.superlink.net wrote:

<snip> 
> We're getting tied in unnecessary and irrelevant knots here.
> 
> My code *does* take everything in stride, and work correctly, in Ruby
> 1.6.8.  There is a change in Ruby 1.8.0 that makes it not work.  I
> don't think I can be expected to have anticipated this change when I
> wrote the code in August.

Perhaps not, but IMHO it's more useful to have the new behavior.

Focusing on this change seems a bit of a red herring to me... if you've
changed SpecializedString#to_i, is it not possible to use your new
semantics?  Or is it not possible to provide the old behavior as a
default? You _should_ predict problems a change in #to_i semantics might
cause, because semantic changes usually cause problems.

> My code was not "trying to do something that's not allowed."  I did
> not change the semantics of String#to_i; I subclassed String and
> overrode a method.  String#to_i is completely unchanged.

Well, it seems logical that if you're working with SpecializedString,
it's natural that operations on itself return other SpecializedString
objects.  This seems to be a positive change in 1.8.  Is it not possible
for your code to work with the SpecializedString class in these cases?

> >   *  Changing a method to do something illogical is possible but
> >      questionable.
> 
> This is of course true, but very far afield from my question.

True, but I was addressing the quote "presumably the overridden version
would do something different from the String version".  Such a change
is illogical... if to_i no longer converts the string to an int, what
does it do?

> To bring us back on track: what we're discussing is not whether or how
> to override methods in subclasses, but the relative merits of the two
> behaviors of Regexp#match.  Either behavior can be accomodated; I
> simply want to know the history of why the new one was chosen.
<snip>

Ah.  Well, the reason above sprang to mind for me; I'll be interested
to hear the real reason. ;)  Just my 0b10.

-- 
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@...>