From: "Eregon (Benoit Daloze) via ruby-core" Date: 2023-06-29T13:05:59+00:00 Subject: [ruby-core:114051] [Ruby master Bug#19749] Confirm correct behaviour when attaching private method with `#define_method` 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 # (NoMethodError)` -- https://bugs.ruby-lang.org/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/