Issue #19749 has been updated by Eregon (Benoit Daloze). jeremyevans0 (Jeremy Evans) wrote in #note-7:
`define_method` at top level does not define private methods. I think this is because the receiver of the `define_method` is `main`, but the method is defined in `Object`, so the scope visibility does not apply. I don't think this is a bug, see #9005.
OK, so it compares the default definee and the receiver of `define_method` then, and only considers scope visibility if they are the same. I'll try to implement that. I suppose that's what `rb_vm_cref_in_context()` does but that's pretty cryptic.
I think `define_method`/`define_singleton_method` should be changed to reset the method visibility if the current method body is passed, either to the scope visibility if the receiver is the same as the current scope, or to public otherwise.
Agreed, whether there is already a method with that name or not shouldn't change anything for `define_method`/`define_singleton_method`. ---------------------------------------- Bug #19749: Confirm correct behaviour when attaching private method with `#define_method` https://bugs.ruby-lang.org/issues/19749#change-103713 * Author: itarato (Peter Arato) * Status: Open * Priority: Normal * ruby -v: 3.3.0 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This issue is a special case of https://bugs.ruby-lang.org/issues/19745: Should dynamically added private methods via `.singleton_class.send(:define_method,...` at the top-level be accessible publicly? See the following example: ```ruby def bar; end foo = Object.new foo.singleton_class.define_method(:bar, method(:bar)) foo.bar # No error. ``` The script above runs fine on latest Ruby 3.3. Is this correct to ignore the fact that the visibility in the caller context is the default top-level private visibility? This came up during a TruffleRuby investigation (https://github.com/oracle/truffleruby/issues/3134) where the result for the same script is: `private method 'bar' called for #<Object:0xc8> (NoMethodError)` -- https://bugs.ruby-lang.org/