Issue #19745 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Closed It is expected that `define_singleton_method` defines a public singleton method (see #18561). For `define_method`, visibility can depend on the current default visibility for the class/module scope. In any case, the visibility of the defined method does not depend on the method body (second argument/block). So this would be a bug in TruffleRuby. ---------------------------------------- Bug #19745: Confirm correct behaviour when attaching private method with `#define_method`/`#define_singleton_method` https://bugs.ruby-lang.org/issues/19745#change-103692 * Author: itarato (Peter Arato) * Status: Closed * Priority: Normal * ruby -v: HEAD * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Should dynamically added private methods be accessible publicly? See the following example? ```ruby private def bar; end foo = Object.new foo.define_singleton_method(:bar, method(:bar)) foo.bar # No error. ``` The script above runs fine on latest Ruby HEAD. Is this correct to ignore the fact that the added method (`method(:bar)`) is private? 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/