Bug #5759

flatten calls to_ary on everything

Added by Thomas Sawyer over 2 years ago. Updated over 1 year ago.

[ruby-core:41634]
Status:Rejected
Priority:Normal
Assignee:Nobuyoshi Nakada
Category:-
Target version:1.9.3
ruby -v:ruby 1.9.3dev (2011-09-23 revision 33323) [x86_64-linux] Backport:

Description

I often ensure that I have an array by doing:

def foo=(x)
@foo = [x].flatten
end

But this has turned into a problem as of late, as it seems #flatten is calling #toary on every element in the array, and apparently catching the error raised if #toary isn't defined for that object. But that causes potential issues with objects that use #method_missing. I think #flatten should use respond_to?(:to_ary) to make sure an object can handle it before actually calling it.


Related issues

Related to ruby-trunk - Bug #6039: lambda vs proc; #to_ary w/ splat bug Rejected 02/17/2012

History

#1 Updated by Eric Hodel over 2 years ago

Use Kernel#Array:

$ ruby -e 'p Array("a\nb"), Array(["a\nb"])'
["a\nb"]
["a\nb"]

#2 Updated by Alex Young over 2 years ago

On 14/12/11 01:05, Eric Hodel wrote:

Issue #5759 has been updated by Eric Hodel.

Use Kernel#Array:

$ ruby -e 'p Array("a\nb"), Array(["a\nb"])'
["a\nb"]
["a\nb"]

Or a splat:

ruby-1.9.3-p0 :001 > a="a\nb"; [a]
=> ["a\nb"]
ruby-1.9.3-p0 :002 > a=["a\nb"]; [
a]
=> ["a\nb"]

Not sure I disagree that #flatten should check first (or just leave the
exception uncaught) though.

--
Alex


Bug #5759: flatten calls to_ary on everything
http://redmine.ruby-lang.org/issues/5759

Author: Thomas Sawyer
Status: Open
Priority: Normal
Assignee:
Category:
Target version: 1.9.3
ruby -v: ruby 1.9.3dev (2011-09-23 revision 33323) [x86_64-linux]

I often ensure that I have an array by doing:

def foo=(x)
@foo = [x].flatten
end

But this has turned into a problem as of late, as it seems #flatten is calling #toary on every element in the array, and apparently catching the error raised if #toary isn't defined for that object. But that causes potential issues with objects that use #method_missing. I think #flatten should use respond_to?(:to_ary) to make sure an object can handle it before actually calling it.

#4 Updated by Koichi Sasada about 2 years ago

  • Assignee set to Nobuyoshi Nakada

#5 Updated by Shyouhei Urabe about 2 years ago

  • Status changed from Open to Assigned

#6 Updated by Nobuyoshi Nakada over 1 year ago

  • Status changed from Assigned to Rejected

When you define methodmissing, you have to also define respondto_missing? properly.

#7 Updated by Thomas Sawyer over 1 year ago

=begin
Isn't the the problem that it doesn't bother to check (({#respond_to?})) at all?

class Baz
def method_missing(s)
s
end

def respond_to_missing?(s, x)
  return false if s == :to_ary
  true
end

end

b = Baz.new
b.respondto?(:toary) #=> false
[Baz.new].flatten
=> in `flatten': can't convert Baz to Array (Baz#to_ary gives Symbol) (TypeError)

=end

#8 Updated by Jeremy Kemper over 1 year ago

class Baz; def respondto?(s, x) super unless s == :toary end end
=> nil
[Baz.new].flatten
=> [#Baz:0x007f8d3115c7d0]

#9 Updated by Thomas Sawyer over 1 year ago

=begin
So it does call (({#respondto?})) after all? Yet, I thought (({#respondtomissing?})) was invented so people would not have to override (({#respondto?})). What's my misunderstanding? Surely we are not now expected to define both?
=end

Also available in: Atom PDF