[#6660] Ruby on Neko ? — Nicolas Cannasse <ncannasse@...>

Hi folks,

14 messages 2005/11/19

[#6672] testing for hardlink with "test(?-, ...)" flawed on Windows — noreply@...

Bugs item #2858, was opened at 2005-11-20 16:35

13 messages 2005/11/20

[#6684] semenatics of if/unless/while statement modifiers — Stefan Kaes <skaes@...>

Hi all,

81 messages 2005/11/21
[#6685] Re: semenatics of if/unless/while statement modifiers — Mauricio Fern疣dez <mfp@...> 2005/11/22

On Tue, Nov 22, 2005 at 08:22:59AM +0900, Stefan Kaes wrote:

[#6686] Re: semenatics of if/unless/while statement modifiers — Stefan Kaes <skaes@...> 2005/11/22

Mauricio Fern疣dez wrote:

[#6687] Re: semenatics of if/unless/while statement modifiers — Eric Hodel <drbrain@...7.net> 2005/11/22

On Nov 21, 2005, at 4:37 PM, Stefan Kaes wrote:

[#6689] Re: semenatics of if/unless/while statement modifiers — Stefan Kaes <skaes@...> 2005/11/22

Eric Hodel wrote:

[#6693] Re: semenatics of if/unless/while statement modifiers — Yukihiro Matsumoto <matz@...> 2005/11/22

Hi,

[#6695] Re: semenatics of if/unless/while statement modifiers — Stefan Kaes <skaes@...> 2005/11/22

Yukihiro Matsumoto wrote:

[#6718] Re: semenatics of if/unless/while statement modifiers — mathew <meta@...> 2005/11/22

[#6722] Re: semenatics of if/unless/while statement modifiers — Stefan Kaes <skaes@...> 2005/11/22

mathew wrote:

[#6707] Re: semenatics of if/unless/while statement modifiers — "David A. Black" <dblack@...> 2005/11/22

Hi --

[#6708] Re: semenatics of if/unless/while statement modifiers — Stefan Kaes <skaes@...> 2005/11/22

David A. Black wrote:

[#6714] Re: semenatics of if/unless/while statement modifiers — "David A. Black" <dblack@...> 2005/11/22

Hi --

[#6717] Re: semenatics of if/unless/while statement modifiers — Stefan Kaes <skaes@...> 2005/11/22

David A. Black wrote:

[#6798] ruby 1.8.4 preview2 — Yukihiro Matsumoto <matz@...>

Hi,

37 messages 2005/11/30

alarming changes

From: "Ara.T.Howard" <ara.t.howard@...>
Date: 2005-11-16 19:17:49 UTC
List: ruby-core #6636
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]

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?  meaning,
shouldn't this

   harp:~ > ruby -e' class C < Array;end; p C::new.map{}.class '
   Array

print 'C' to be consistent with the above?  why the difference?  what's the
grand plan?

regards.

-a
-- 
===============================================================================
| ara [dot] t [dot] howard [at] gmail [dot] com
| all happiness comes from the desire for others to be happy.  all misery
| comes from the desire for oneself to be happy.
| -- bodhicaryavatara
===============================================================================


In This Thread

Prev Next