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
[e-mail]