From: shugo@... Date: 2021-07-20T07:53:37+00:00 Subject: [ruby-core:104651] [Ruby master Bug#17429] Prohibit include/prepend in refinement modules Issue #17429 has been updated by shugo (Shugo Maeda). Eregon (Benoit Daloze) wrote in #note-20: > One more issue reported due these confusing semantics of include/prepend inside `refine`: #18021. > > I suggest we warn in 3.1, raise in 3.2. > And I suggest to add `Refinement#import`, because: > * `mix` seems to imply other things, and if it's ever added to Module with different semantics we will just get more confusion. > * `include` seems likely to cause confusion because the behavior would not be Module#include-like. It is also potentially backward-incompatible, raises the question about what would happen for `prepend` and consistency. And finnaly `include` would not longer mean "define higher in the ancestor" for this context, i.e., defining the same method in the refine block would replace, not just override). I've implemented Refinement#import in https://github.com/shugo/ruby/pull/3 In the current implementation, the module in cref is replaced with the refinement like Module#dup, so constants in the imported module are not accessible from the copied methods. It would be possible to support constant access with a hack on cref, but I'm afraid it may bring new problems. Maybe Refinement#import_methods is a better name if we keep the current behavior. ---------------------------------------- Bug #17429: Prohibit include/prepend in refinement modules https://bugs.ruby-lang.org/issues/17429#change-92960 * Author: shugo (Shugo Maeda) * Status: Open * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- include/prepend in refinement modules has implementation difficulties such as #17007 and #17379, and tends to be misleading like #17374. How about to prohibit it in future versions? Method copy like #17380 may be more convenient, but it's confusing to use names include and prepend because semantics is different from the original ones. -- https://bugs.ruby-lang.org/ Unsubscribe: