Ruby » Ruby master

Bug #6087

Updated by nobu (Nobuyoshi Nakada) over 4 years ago

Just noticed that we still don't have a consistent way to handle return values: 

 ```ruby 
 

   class A < Array 
 
   end 
 
   a = A.new 
 
   a.flatten.class # => A 
 
   a.rotate.class    # => Array 
 
   (a * 2).class     # => A 
 
   (a + a).class     # => Array 
 ``` 

 Some methods are even inconsistent depending on their arguments: 

 ```ruby 
 

   a.slice!(0, 1).class # => A 
 
   a.slice!(0..0).class # => A 
 
   a.slice!(0, 0).class # => Array 
 
   a.slice!(1, 0).class # => Array 
 
   a.slice!(1..0).class # => Array 
 ``` 

 Finally, there is currently no constructor nor hook called when making these new copies, so they are never properly constructed. 

 Imagine this simplified class that relies on `@foo` holding a hash: 

 ```ruby 
 

   class A < Array 
   
     def initialize(*args) 
     
       super 
     
       @foo = {} 
   
     end 

   
  
     def initialize_copy(orig) 
     
       super 
     
       @foo = @foo.dup 
     end 
   end 
 end 
 
   a = A.new.flatten 
 
   a.class # => A 
 
   a.instance_variable_get(:@foo) # => nil, should never happen 
 ``` 

 I feel this violates object orientation. 


 One solution is to always return the base class (`Array`/`String`/...). (Array/String/...). 

 Another solution is to return the current subclass. To be object oriented, I feel we must do an actual `dup` of the object, including copying the instance variables, if any, and calling `initialize_copy`. Exceptions to this would be (1) explicit documentation, e.g. `Array#to_a`, Array#to_a, or (2) methods inherited from a module (like `Enumerable` Enumerable methods for `Array`). Array). 

 I'll be glad to fix these once there is a decision made on which way to go. 

Back