[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: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>