From: alxtskrnk@... Date: 2016-08-24T14:43:03+00:00 Subject: [ruby-core:77042] [Ruby trunk Feature#12697] Why shouldn't Module meta programming methods be public? Issue #12697 has been updated by bug hit. Yukihiro Matsumoto wrote: > I still believe > > ``` > class String > include Term::ANSIColor > end > ``` > > is far better than `String.include Term::ANSIColor`. It is clearer and has more space to optimize. > Besides that the fact that `include` etc may have huge performance penalty is also a reason to prohibit casual class/module modification. Is there any reason to allow this in addition to saving extra few keystrokes? > > Matz. In meta programming scenarios you are not including or defining literals at top level but expressions and often in methods, so it's not ```ruby class Class1 include Module1 define_method(:method1) attr_accessor(:attr1) end ``` but ```ruby def self.do_some_meta_programming(module, method, attr) Class1.send(:include, module) Class1.send(:define_method, method){} Class1.send(:attr_accessor, attr) end ``` So yes, :send, and :class_eval is less convenient and unnecessary. This is not the way to communicate that meta programming may have a performance penalty, the way to do that is documentation. ---------------------------------------- Feature #12697: Why shouldn't Module meta programming methods be public? https://bugs.ruby-lang.org/issues/12697#change-60267 * Author: bug hit * Status: Feedback * Priority: Normal * Assignee: Yukihiro Matsumoto ---------------------------------------- Methods like alias_method, attr_accessor, define_method, and similar I don't think Ruby discourages this kind of meta programming, so why make it less convenient, by necessitating `send` or `module_eval`? -- https://bugs.ruby-lang.org/ Unsubscribe: