Issue #19749 has been updated by Eregon (Benoit Daloze). @jeremyevans0 That does not explain why the original example defines the method as public (note I edited the description on Redmine, it was not asking the right question).

will only consider current default scope visibility to determine visibility:

And that visibility is private at the top-level. So why is the method defined as public on CRuby? ---------------------------------------- Bug #19749: Confirm correct behaviour when attaching private method with `#define_method` https://bugs.ruby-lang.org/issues/19749#change-103703 * Author: itarato (Peter Arato) * Status: Closed * 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.send(: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/

Issue #19749 has been updated by jeremyevans0 (Jeremy Evans). Eregon (Benoit Daloze) wrote in #note-3:

@jeremyevans0 That does not explain why the original example defines the method as public (note I edited the description on Redmine, it was not asking the right question).

...

will only consider current default scope visibility to determine visibility:

And that visibility is private at the top-level. So why is the method defined as public on CRuby?

Scope visibility is only used if the receiver of the method is the same as current scope, which was not the case in the previous examples given. `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. However, I think there is a bug here, in that `define_method` will not change the existing visibility of a method if `define_method` is called with the current method body: ```ruby def bar; end define_method(:bar, method(:bar)) Object.new.bar # NoMethodError ``` This is not related to top-level: ```ruby class Foo def bar; end define_method(:bar, method(:bar)) new.bar # NoMethodError end ``` Note that `define_method` does not copy the method body visibility if there is not an existing method entry: ```ruby def bar; end define_method(:baz, method(:bar)) Object.new.baz # no error ``` It will override the method visibility if the method is already defined but does not have the same implementation, but in that case it will not use the method body visibility: ```ruby def bar; end def baz; end define_method(:baz, method(:bar)) Object.new.baz # no error ``` This also affects `define_singleton_method`: ```ruby foo = Object.new foo.singleton_class.class_exec do private def bar; end end foo.define_singleton_method(:bar, foo.method(:bar)) foo.bar # NoMethodError ``` 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. ---------------------------------------- Bug #19749: Confirm correct behaviour when attaching private method with `#define_method` https://bugs.ruby-lang.org/issues/19749#change-103708 * 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/

Issue #19749 has been updated by Eregon (Benoit Daloze). I find it very surprising/unintuitive that `define_method` sometimes ignores the scope visibility, with hard-to-explain and undocumented conditions, but `def` always respects the scope visibility (AFAIK, not counting "defs"=`def r.m`). A metaprogramming API should as much as possible be equivalent to the non-metaprogramming API. ---------------------------------------- Bug #19749: Confirm correct behaviour when attaching private method with `#define_method` https://bugs.ruby-lang.org/issues/19749#change-103714 * 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/

Issue #19749 has been updated by jeremyevans0 (Jeremy Evans). I submitted a pull request to fix this: https://github.com/ruby/ruby/pull/8009 ---------------------------------------- Bug #19749: Confirm correct behaviour when attaching private method with `#define_method` https://bugs.ruby-lang.org/issues/19749#change-103728 * 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/

Issue #19749 has been updated by jeremyevans0 (Jeremy Evans). I don't think my discussion from comment #7 was considered during the dev meeting. Discussion focused on general `define_method` behavior, which I don't think is a bug. I should have been more clear in the dev meeting ticket exactly what I would like to fix. Here's a reduced example showing the problem: ```ruby class A def a; end private def b; end m = instance_method(:b) define_method(:c, m) # defines public method define_method(:b, m) # defines private method, should define public method private m = instance_method(:a) define_method(:d, m) # defines private method define_method(:a, m) # defines public method, should define private method p public_instance_methods(false) # => [:c, :a] # should be [:c, :b] p private_instance_methods(false) # => [:b, :d] # should be [:a, :d] end ``` I think this particular behavior of not changing visibility of a method when calling `define_method` with the same method body is a bug that should be fixed. ---------------------------------------- Bug #19749: Confirm correct behaviour when attaching private method with `#define_method` https://bugs.ruby-lang.org/issues/19749#change-103855 * 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/

Issue #19749 has been updated by mame (Yusuke Endoh). @jeremyevans0 Thanks, so the question is whether visibility should be updated when redefining a method by `define_method` with the method itself. ```ruby class C def foo; end private define_method(:foo, method(:foo)) # current: the method foo is kept public # expected: the method foo is changed private end ``` @matz What do you think? ---------------------------------------- Bug #19749: Confirm correct behaviour when attaching private method with `#define_method` https://bugs.ruby-lang.org/issues/19749#change-103879 * 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/

Issue #19749 has been updated by mame (Yusuke Endoh). Discussed at the dev meeting. @matz said `define_method(:foo, instance_method(:foo))` should change the visibility of `foo` to that of the current context. ---------------------------------------- Bug #19749: Confirm correct behaviour when attaching private method with `#define_method` https://bugs.ruby-lang.org/issues/19749#change-108690 * Author: itarato (Peter Arato) * Status: Open * 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/