Fixes https://github.com/pry/pry/issues/1596
(Unable to inspect object built from class)
Replaces https://github.com/pry/pry/pull/1719
Big thanks to @egwspiti for the repro case and the proposed PR.
When a class redefines `respond_to?` or `method_missing` this leads to some
problems and confuses Pry. I found another example where Pry misbehaves:
```
[1] pry(main)> cd Class.new { def method_missing(*) end; def respond_to_missing?(*) true end; }.new
NoMethodError: private method `eval' called for nil:NilClass
from /Users/kyrylo/.gem/ruby/2.4.2/gems/pry-0.11.3/lib/pry/pry_instance.rb:163:in `inject_local'
```
By using `method_defined?` we can work around these bugs since this method
doesn't check whether the receiver responds to a certain message but checks
whether this method is defined (so we don't redefine it later). Seems like a
win-win.
Removes Bacon and Mocha
Reasoning explained in this comment: https://github.com/pry/pry/issues/277#issuecomment-51708712
Mostly this went smoothly. There were a few errors that I fixed along
the way, e.g. tests that were failing but for various reasons still
passed. Should have documented them, but didn't think about it until
very near the end. But generaly, I remember 2 reasons this would happen:
`lambda { raise "omg" }.should.raise(RuntimeError, /not-omg/)` will pass
because the second argument is ignored by Bacon. And `1.should == 2`
will return false instead of raising an error when it is not in an it
block (e.g. if stuck in a describe block, that would just return false)
The only one that I felt unsure about was spec/helpers/table_spec.rb
`Pry::Helpers.tablify_or_one_line('head', %w(ing)).should == 'head: ing'`
This is wrong, but was not failing because it was in a describe block
instead of an it block. In reality, it returns `"head: ing\n"`,
I updated the test to reflect this, though I don't know for sure
this is the right thing to do
This will fail on master until https://github.com/pry/pry/pull/1281 is merged.
This makes https://github.com/pry/pry/pull/1278 unnecessary.
This fixes#957 and should make object path resolution more predictable
in general. Instead of splitting the path on "/" before doing any
parsing, we use `StringScanner` and `complete_expression?` to scan
through the string looking for complete slash-delimited Ruby
expressions.
It also turned out that separating the code for handling "-" from the
path-resolution code simplified things a lot. It doesn't really make
sense for "-" to be in there anyway, since paths like "foo/-/bar" don't
mean anything.
