defunkt/fakefs — pull request #213 by tovodeverett (2014-01-16 23:46:16+00:00)
Title: Updated method signature for FakeFS::FakeSymlink#respond_to?

* Old version only accepted one parameter, which was no longer correct
as of Ruby 1.8.6 (or older - I can't tell when the change happened).
* Test suite validates the method accepts both parameters and that
the behavior is implemented correctly. It also validates that the
default values are resolved correctly. Note that the change in
behavior in Ruby 2.0.0 for the second parameter was implemented by
modifying the meaning of the second parameter (from `include_priv`
to `include_all`) rather than changing the default value (which
remained `false`), but it is still better not to copy method
signatures if possible.

Note that this closes the following warning that was cropping up when running the test suite under 2.0.0:

```
FakeFSTest#test_cp_r_only_copies_into_directories/home/travis/build/defunkt/fakefs/lib/fakefs/fake/dir.rb:28: warning: FakeFS::FakeSymlink#respond_to?(:marshal_dump) is old fashion which takes only one parameter
/home/travis/build/defunkt/fakefs/lib/fakefs/fake/symlink.rb:25: warning: respond_to? is defined here
/home/travis/build/defunkt/fakefs/lib/fakefs/fake/dir.rb:28: warning: FakeFS::FakeSymlink#respond_to?(:_dump) is old fashion which takes only one parameter
/home/travis/build/defunkt/fakefs/lib/fakefs/fake/symlink.rb:25: warning: respond_to? is defined here
```

There is still an issue with binary data that I will investigate.