Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Changing method visibility changes method ownership, but doesn't on MRI #2565

Closed
myronmarston opened this issue Feb 5, 2015 · 5 comments
Closed

Changing method visibility changes method ownership, but doesn't on MRI #2565

myronmarston opened this issue Feb 5, 2015 · 5 comments
Milestone
Invalid or Duplicate

Comments

@myronmarston
Copy link

I'm noticing that when you change method visibility on JRuby, it has a side effect that's not present on MRI: it changes what Method#owner returns.

First, here's the behavior on MRI 2.2:

➜  ~  ruby -v
ruby 2.2.0p0 (2014-12-25 revision 49005) [x86_64-darwin12.0]
➜  ~  ruby -e "class A; private_class_method :new; end; puts A.method(:new).owner"
Class
➜  ~  ruby -e "class A; private :inspect; end; puts A.instance_method(:inspect).owner"
Kernel

It looks like this has always been MRI's behavior; on 1.8.7 I see the same thing:

➜  ~  ruby -v
ruby 1.8.7 (2013-12-22 patchlevel 375) [i686-darwin12.5.0]
➜  ~  ruby -e "class A; private_class_method :new; end; puts A.method(:new).owner"
Class
➜  ~  ruby -e "class A; private :inspect; end; puts A.instance_method(:inspect).owner"
Kernel

Compare that to JRuby's behavior:

➜  ~  ruby -v
jruby 1.7.8 (1.9.3p392) 2013-11-14 0ce429e on Java HotSpot(TM) 64-Bit Server VM 1.6.0_65-b14-462-11M4609 [darwin-x86_64]
➜  ~  ruby -e "class A; private_class_method :new; end; puts A.method(:new).owner"
#<Class:A>
➜  ~  ruby -e "class A; private :inspect; end; puts A.instance_method(:inspect).owner"
A
myronmarston added a commit to rspec/rspec-mocks that referenced this issue Feb 5, 2015
@myronmarston
Pend specs to deal with jruby/jruby#2565.
8056a9e
@pirj
Copy link
Contributor

pirj commented Nov 15, 2020

@headius The following rspec-mocks example passes just fine on jruby 9.2.13.0 (2.5.7) 2020-08-03 9a89c94bcc:

          it 'uses the method signature from `#initialize` for arg verification' do
            # Commented it out and it still passes ❤️ 
            # pending "Failing on JRuby due to https://github.com/jruby/jruby/issues/2565" if RSpec::Support::Ruby.jruby?

            subclass = Class.new(klass) do
              private_class_method :new
            end

            prevents(/arguments/) { allow(subclass).to receive(:new).with(1) }
            allow(subclass).to receive(:new).with(1, 2)
          end

Also, as reported originally:

$ ruby --version
jruby 9.2.13.0 (2.5.7) 2020-08-03 9a89c94bcc OpenJDK 64-Bit Server VM 14.0.1+14 on 14.0.1+14 +jit [darwin-x86_64]
$ ruby -e "class A; private_class_method :new; end; puts A.method(:new).owner"
Class
$ ruby -e "class A; private :inspect; end; puts A.instance_method(:inspect).owner"
Kernel

This seems to have been fixed, so I guess this issue can be closed.

Thanks!

@headius
Copy link
Member

headius commented Nov 16, 2020

Thanks for the update! This was probably fixed when we reworked how method tables function to better support unusual super cases.

@headius headius closed this as completed Nov 16, 2020
@headius headius added this to the Invalid or Duplicate milestone Nov 16, 2020
@eregon
Copy link
Member

eregon commented Apr 19, 2022 •
edited

FWIW, I think the behavior is actually a CRuby bug: https://bugs.ruby-lang.org/issues/18729
The owner should always be the module/class on which the method is defined AFAIK.
I'm not sure how come RSpec depends on what seems to be a CRuby bug, @bjfish will take a look.

@headius
Copy link
Member

headius commented Apr 21, 2022

I think you meant to link to https://bugs.ruby-lang.org/issues/18729.

@eregon
Copy link
Member

eregon commented Apr 21, 2022

Oops, indeed, I edited my comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
Invalid or Duplicate
Development

No branches or pull requests
4 participants
@pirj @headius @myronmarston @eregon