Project

General

Profile

Actions

Bug #5759

closed

flatten calls to_ary on everything

Added by trans (Thomas Sawyer) over 12 years ago. Updated about 11 years ago.

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

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 #to_ary on every element in the array, and apparently catching the error raised if #to_ary 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 1 (0 open1 closed)

Related to Ruby master - Bug #6039: lambda vs proc; #to_ary w/ splat bugRejectedmatz (Yukihiro Matsumoto)02/17/2012Actions

Updated by drbrain (Eric Hodel) over 12 years ago

Use Kernel#Array:

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

Updated by regularfry (Alex Young) over 12 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 #to_ary on every element in the array, and apparently catching the error raised if #to_ary 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.

Actions #4

Updated by ko1 (Koichi Sasada) about 12 years ago

  • Assignee set to nobu (Nobuyoshi Nakada)
Actions #5

Updated by shyouhei (Shyouhei Urabe) about 12 years ago

  • Status changed from Open to Assigned

Updated by nobu (Nobuyoshi Nakada) about 11 years ago

  • Status changed from Assigned to Rejected

When you define method_missing, you have to also define respond_to_missing? properly.

Updated by trans (Thomas Sawyer) about 11 years 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.respond_to?(:to_ary) #=> false
[Baz.new].flatten
=> in `flatten': can't convert Baz to Array (Baz#to_ary gives Symbol) (TypeError)

=end

Updated by bitsweat (Jeremy Daer) about 11 years ago

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

Updated by trans (Thomas Sawyer) about 11 years ago

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

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0