From: "David A. Black" Date: 2005-11-17T11:53:33+09:00 Subject: Re: alarming changes Hi -- On Thu, 17 Nov 2005, Ara.T.Howard wrote: > > is this by design? > > > [ahoward@jib dmsp-2.1.0]$ ruby -v > ruby 1.8.1 (2003-12-25) [i686-linux] > [ahoward@jib dmsp-2.1.0]$ ruby -e' class C < String;end; p > %r/42/.match(C::new("42")).to_a.map{|x| x.class} ' > [String] > > [ahoward@localhost ~]$ ruby -v > ruby 1.8.2 (2005-02-12) [i686-linux] > [ahoward@localhost ~]$ ruby -e' class C < String;end; p > %r/42/.match(C::new("42")).to_a.map{|x| x.class} ' > [C] > > [nrt@mussel dmsp-2.1.0]$ ruby -v > ruby 1.8.3 (2005-06-20) [i686-linux] > [nrt@mussel dmsp-2.1.0]$ ruby -e' class C < String;end; p > %r/42/.match(C::new("42")).to_a.map{|x| x.class} ' > [C] Similarly: irb(main):006:0> /(42)/.match(C.new("42")).captures[0].class => C > i went through the ChangeLog but didn't see anything that jumped out. the > change makes sense - but will in continue to be this way? is the move to > return appropriate sub-classed values meant to be pervasive? I think the appropriateness is questionable. I guess the point would be to make it easier to subclass built-in classes. But it actually sort of constrains what you can do. For example: irb(main):012:0> def C.new(str); raise ArgumentError, "C's can't be shorter than 5 characters" if str.size < 5; super(str); end => nil irb(main):013:0> C.new('abcde')[0,2] => "ab" irb(main):014:0> C.new('abcde')[0,2].class So it doesn't really provide a whole mechanism for building on built-ins. There's probably more to the rationale for it, though. David -- David A. Black dblack@wobblini.net