protected methods can be called from modules
Reported by Scott Taylor | February 26th, 2008 @ 03:00 AM
With these specs:
module Foo
protected
def test_protected
"hello"
end
private
def test_private
"foo"
end
end
describe Foo do
before :each do
@klass = Class.new do
include Foo
end
@object = @klass.new
end
it "should NOT raise an error when calling a protected method (because it's included)" do
lambda {
test_protected
}.should_not raise_error
end
it "should raise an error when calling a private method (because it's included)" do
lambda {
test_private
}.should_not raise_error
end
it "should raise an error when calling a private method on an object which includes the module" do
lambda {
@object.test_private
}.should raise_error
end
it "should raise an error when calling a protected method on an object which includes the module" do
lambda {
@object.test_protected
}.should raise_error
end
end
The last spec fails on ruby 1.8.6 patchlevel 111 (with rspec gem 1.1.3, on OS X):
Mac-Pro-1:1_8_5_test scott$ spec spec/1_8_5_spec.rb
...F
1)
'Foo should raise an error when calling a private method on an object which includes the module' FAILED
expected Exception but nothing was raised
./spec/1_8_5_spec.rb:42:
Finished in 0.005779 seconds
On ruby 1.8.5 (gentoo), it passes:
[deploy@rm-207-210-123-165 ~]$ spec tmp_spec.rb
....
Finished in 0.011212 seconds
Comments and changes to this ticket
-
-
David Chelimsky February 26th, 2008 @ 05:38 AM
- → State changed from “new” to “invalid”
Actually this makes sense.
Protected methods are accessible by other objects that include the same module in which they are defined:
module A protected def protected_method "protected method" end end class B include A end class C include A def call(other) other.protected_method end end b = B.new c = C.new c.call(b) => "protected method"Since the spec includes the module and so does the object, the spec has access to the method.
Now we've been thinking about deprecating the auto-inclusion because it causes exactly this sort of confusion, but that's a separate matter.
WDYT about deprecating that feature?
-
Scott Taylor February 26th, 2008 @ 06:29 AM
Hmm... I guess this was a change in 1.8.6?
I'm all for deprecating it - the only time I've seen it to be useful is in in Rails Helper specs. How about deprecating it (issuing a warning for those who might depend on it currently) for rspec, but leaving it in for behaviour types of :helper (in rspec_on_rails)?
-
David Chelimsky March 2nd, 2008 @ 07:15 PM
Scott - FYI - there is already support (in svn trunk and git) for a helper object in rails' helper specs:
describe ThingHelper do it "should make stuff" do helper.make_something.should have_tag(...) end end -
David Chelimsky March 2nd, 2008 @ 07:16 PM
Also - I can't really think of a fool-proof way of providing a programatic deprecation warning for this, can anyone else?
-
Scott Taylor March 3rd, 2008 @ 12:27 AM
How about using a method added hook. I've attached some code to show the concept (although it has no specs, and could be more careful with a method's arity).
-
David Chelimsky March 3rd, 2008 @ 12:31 AM
- → Assigned user changed from “” to “David Chelimsky”
That seems like it would work - do you want to make a full blown patch w/ specs?
-
Scott Taylor April 5th, 2008 @ 08:11 AM
David,
Don't know if you've missed it, but there is a full blown patch with ticket #326.
I wasn't able to finish pre_commit on that patch because of issues with webby. Have those issues been resolved?
Please Login or create a free account to add a new comment.
You can update this ticket by sending an email to from your email client. (help)
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
Behaviour Driven Development for Ruby.
