Forum: Ruby-core [ruby-trunk - Bug #8153][Open] Problems with Enumerable#zip caused by overriding Object#respond_to?

Issue #8153 has been reported by mjtko (Mark Titorenko).

----------------------------------------
Bug #8153: Problems with Enumerable#zip caused by overriding 
Object#respond_to?
https://bugs.ruby-lang.org/issues/8153

Author: mjtko (Mark Titorenko)
Status: Open
Priority: Normal
Assignee:
Category:
Target version:
ruby -v: ruby 2.0.0p0 (2013-02-24 revision 39474) [x86_64-darwin12.2.0]


If I override Object#respond_to? under Ruby 2.0.0, Enumerable#zip begins 
to misbehave.  Here is the code and output in Ruby 2.0.0:

2.0.0p0 :001 > RUBY_VERSION
 => "2.0.0"
2.0.0p0 :002 >  class Object
2.0.0p0 :003?>       alias :_respond_to? :respond_to?
2.0.0p0 :004?>       def respond_to?(*a)
2.0.0p0 :005?>           _respond_to?(*a)
2.0.0p0 :006?>         end
2.0.0p0 :007?>     end
 => nil
2.0.0p0 :008 > [1,2,3].zip((1..3).each)
 => [[1, nil], [2, nil], [3, nil]]

Should be: [[1, 1], [2, 2], [3, 3]]

Here is the output I was expecting, generated in Ruby 1.9.3 -- ruby 
1.9.3p392 (2013-02-22 revision 39386) [x86_64-darwin12.2.0]:

1.9.3p392 :001 > RUBY_VERSION
 => "1.9.3"
1.9.3p392 :002 >  class Object
1.9.3p392 :003?>       alias :_respond_to? :respond_to?
1.9.3p392 :004?>       def respond_to?(*a)
1.9.3p392 :005?>           _respond_to?(*a)
1.9.3p392 :006?>         end
1.9.3p392 :007?>     end
 => nil
1.9.3p392 :008 > [1,2,3].zip((1..3).each)
 => [[1, 1], [2, 2], [3, 3]]
1.9.3p392 :009 >

I'm not certain if this is the only method which is interfered with, but 
it's how I determined an issue was present initially.

For copy and paste convenience:

class Object
    alias :_respond_to? :respond_to?
    def respond_to?(*a)
      _respond_to?(*a)
    end
end

[1,2,3].zip((1..3).each)

FWIW, the same behaviour occurs if using a prepend-ed module and super:

  module RespondToBug
    def respond_to?(*a)
      super
    end
  end

  class Object
    prepend RespondToBug
  end

Issue #8153 has been updated by drbrain (Eric Hodel).


Is respond_to_missing? insufficient for your needs?
----------------------------------------
Bug #8153: Problems with Enumerable#zip caused by overriding 
Object#respond_to?
https://bugs.ruby-lang.org/issues/8153#change-37830

Author: mjtko (Mark Titorenko)
Status: Open
Priority: Normal
Assignee:
Category:
Target version:
ruby -v: ruby 2.0.0p0 (2013-02-24 revision 39474) [x86_64-darwin12.2.0]


If I override Object#respond_to? under Ruby 2.0.0, Enumerable#zip begins 
to misbehave.  Here is the code and output in Ruby 2.0.0:

2.0.0p0 :001 > RUBY_VERSION
 => "2.0.0"
2.0.0p0 :002 >  class Object
2.0.0p0 :003?>       alias :_respond_to? :respond_to?
2.0.0p0 :004?>       def respond_to?(*a)
2.0.0p0 :005?>           _respond_to?(*a)
2.0.0p0 :006?>         end
2.0.0p0 :007?>     end
 => nil
2.0.0p0 :008 > [1,2,3].zip((1..3).each)
 => [[1, nil], [2, nil], [3, nil]]

Should be: [[1, 1], [2, 2], [3, 3]]

Here is the output I was expecting, generated in Ruby 1.9.3 -- ruby 
1.9.3p392 (2013-02-22 revision 39386) [x86_64-darwin12.2.0]:

1.9.3p392 :001 > RUBY_VERSION
 => "1.9.3"
1.9.3p392 :002 >  class Object
1.9.3p392 :003?>       alias :_respond_to? :respond_to?
1.9.3p392 :004?>       def respond_to?(*a)
1.9.3p392 :005?>           _respond_to?(*a)
1.9.3p392 :006?>         end
1.9.3p392 :007?>     end
 => nil
1.9.3p392 :008 > [1,2,3].zip((1..3).each)
 => [[1, 1], [2, 2], [3, 3]]
1.9.3p392 :009 >

I'm not certain if this is the only method which is interfered with, but 
it's how I determined an issue was present initially.

For copy and paste convenience:

class Object
    alias :_respond_to? :respond_to?
    def respond_to?(*a)
      _respond_to?(*a)
    end
end

[1,2,3].zip((1..3).each)

FWIW, the same behaviour occurs if using a prepend-ed module and super:

  module RespondToBug
    def respond_to?(*a)
      super
    end
  end

  class Object
    prepend RespondToBug
  end

Issue #8153 has been updated by marcandre (Marc-Andre Lafortune).

Category set to core
Assignee set to marcandre (Marc-Andre Lafortune)

Indeed, using `respond_to_missing?` is typically the preferred way, but 
that's a very odd bug!
----------------------------------------
Bug #8153: Problems with Enumerable#zip caused by overriding 
Object#respond_to?
https://bugs.ruby-lang.org/issues/8153#change-37831

Author: mjtko (Mark Titorenko)
Status: Open
Priority: Normal
Assignee: marcandre (Marc-Andre Lafortune)
Category: core
Target version:
ruby -v: ruby 2.0.0p0 (2013-02-24 revision 39474) [x86_64-darwin12.2.0]


If I override Object#respond_to? under Ruby 2.0.0, Enumerable#zip begins 
to misbehave.  Here is the code and output in Ruby 2.0.0:

2.0.0p0 :001 > RUBY_VERSION
 => "2.0.0"
2.0.0p0 :002 >  class Object
2.0.0p0 :003?>       alias :_respond_to? :respond_to?
2.0.0p0 :004?>       def respond_to?(*a)
2.0.0p0 :005?>           _respond_to?(*a)
2.0.0p0 :006?>         end
2.0.0p0 :007?>     end
 => nil
2.0.0p0 :008 > [1,2,3].zip((1..3).each)
 => [[1, nil], [2, nil], [3, nil]]

Should be: [[1, 1], [2, 2], [3, 3]]

Here is the output I was expecting, generated in Ruby 1.9.3 -- ruby 
1.9.3p392 (2013-02-22 revision 39386) [x86_64-darwin12.2.0]:

1.9.3p392 :001 > RUBY_VERSION
 => "1.9.3"
1.9.3p392 :002 >  class Object
1.9.3p392 :003?>       alias :_respond_to? :respond_to?
1.9.3p392 :004?>       def respond_to?(*a)
1.9.3p392 :005?>           _respond_to?(*a)
1.9.3p392 :006?>         end
1.9.3p392 :007?>     end
 => nil
1.9.3p392 :008 > [1,2,3].zip((1..3).each)
 => [[1, 1], [2, 2], [3, 3]]
1.9.3p392 :009 >

I'm not certain if this is the only method which is interfered with, but 
it's how I determined an issue was present initially.

For copy and paste convenience:

class Object
    alias :_respond_to? :respond_to?
    def respond_to?(*a)
      _respond_to?(*a)
    end
end

[1,2,3].zip((1..3).each)

FWIW, the same behaviour occurs if using a prepend-ed module and super:

  module RespondToBug
    def respond_to?(*a)
      super
    end
  end

  class Object
    prepend RespondToBug
  end

Issue #8153 has been updated by mjtko (Mark Titorenko).


Thanks, glad to hear this has been fixed!

As for using `respond_to_missing?` - I understand the purpose of 
`respond_to_missing?` but, in my case, I was explicitly overriding 
`respond_to?` in order to try and track down bad code that was still 
using the single-argument version for determining the presence of 
protected methods.  This was working fine, but instead was causing other 
code to fail with the `zip` bug as outlined above. :)

----------------------------------------
Backport #8153: Problems with Enumerable#zip caused by overriding 
Object#respond_to?
https://bugs.ruby-lang.org/issues/8153#change-37929

Author: mjtko (Mark Titorenko)
Status: Open
Priority: Normal
Assignee: nagachika (Tomoyuki Chikanaga)
Category:
Target version:


If I override Object#respond_to? under Ruby 2.0.0, Enumerable#zip begins 
to misbehave.  Here is the code and output in Ruby 2.0.0:

2.0.0p0 :001 > RUBY_VERSION
 => "2.0.0"
2.0.0p0 :002 >  class Object
2.0.0p0 :003?>       alias :_respond_to? :respond_to?
2.0.0p0 :004?>       def respond_to?(*a)
2.0.0p0 :005?>           _respond_to?(*a)
2.0.0p0 :006?>         end
2.0.0p0 :007?>     end
 => nil
2.0.0p0 :008 > [1,2,3].zip((1..3).each)
 => [[1, nil], [2, nil], [3, nil]]

Should be: [[1, 1], [2, 2], [3, 3]]

Here is the output I was expecting, generated in Ruby 1.9.3 -- ruby 
1.9.3p392 (2013-02-22 revision 39386) [x86_64-darwin12.2.0]:

1.9.3p392 :001 > RUBY_VERSION
 => "1.9.3"
1.9.3p392 :002 >  class Object
1.9.3p392 :003?>       alias :_respond_to? :respond_to?
1.9.3p392 :004?>       def respond_to?(*a)
1.9.3p392 :005?>           _respond_to?(*a)
1.9.3p392 :006?>         end
1.9.3p392 :007?>     end
 => nil
1.9.3p392 :008 > [1,2,3].zip((1..3).each)
 => [[1, 1], [2, 2], [3, 3]]
1.9.3p392 :009 >

I'm not certain if this is the only method which is interfered with, but 
it's how I determined an issue was present initially.

For copy and paste convenience:

class Object
    alias :_respond_to? :respond_to?
    def respond_to?(*a)
      _respond_to?(*a)
    end
end

[1,2,3].zip((1..3).each)

FWIW, the same behaviour occurs if using a prepend-ed module and super:

  module RespondToBug
    def respond_to?(*a)
      super
    end
  end

  class Object
    prepend RespondToBug
  end