Issue #14133 has been updated by shevegen (Robert A. Heiler).


> Note that many of these are very bad usage of define_method. I feel
> this shows that even beginner programmers will use :send if privacy
> gets in the way. Let's not hinder advanced users in a failed attempt
> to protect the beginners.

.send() is simply awesome. It's a basic OOP way - you send your message
to the object, which will have a look as to what to do, without any 
fuzz.

The rails code looks very alien to me and not very pretty. A lot of
the metaprogramming makes the code hard to read IMO.

I think that people use .send() because it is so much simpler than
the alternatives. One could then also say that the alternatives may
be too complex or complicated. Lots of eval-methods and it is not
always easy to infer which eval method is now the right one or how
to use it.

Some weird code usage is out there too:

    https://github.com/thangit93/yii2/blob/4802d9e0ef7281b50e793e0d3cf7aee3b238d22f/cookbooks/iis/libraries/matcher.rb#L8

    self.class.send(:define_method, "#{action}_iis_app", proc do |app_name|

To your suggestion itself, I have nothing against it, but I guess 
matz has to decide; and perhaps this may have to be for ruby 3.x
rather than the ruby 2.x branch.

----------------------------------------
Feature #14133: Module#{define|alias|undef}_method should be made public
https://bugs.ruby-lang.org/issues/14133#change-67963

* Author: marcandre (Marc-Andre Lafortune)
* Status: Open
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* Target version: 
----------------------------------------
Modules and classes can be reopened and changed (unless frozen).

This is used in many meta programming techniques.

Currently, `define_method` is private, so we need to either do a `class_eval`, reopen the class somehow, or resort to `:send`.

As I previously stated in #6539, I feel that the use of `send` should be reserved for incorrect usage of actually private methods that might change of interface or aren't meant to be called this way (e.g. `respond_to_missing?`, `puts`)

Matz has stated before that "class/module operations should be done in the scope.". Nevertheless, common usage shows that there are many cases where Rubyists prefer using a single line for this, even if it means having to call send.

Here are 95k+ examples of `send :define_method` in the wild:
https://github.com/search?utf8=%E2%9C%93&q=language%3Aruby+%22send+%3Adefine_method%22&type=Code

Note that many of these are very bad usage of `define_method`. I feel this shows that even beginner programmers will use `:send` if privacy gets in the way. Let's not hinder advanced users in a failed attempt to protect the beginners.

Rails has good examples of use of `send :define_method` like https://github.com/rails/rails/blob/master/actionview/lib/action_view/lookup_context.rb#L27
That's despite the fact for most metaprogramming they don't use `define_method` and instead build a string of code and do a `module_eval` for both performance and ease debugging (see the next lines in the example). That's not possible when the new methods must access blocks though, like in the example given.

`alias_method` and `undef_method` can be seen as special cases of `define_method` and should have the same privacy.
55k+ examples of `send :alias_method` in the wild:
https://github.com/search?utf8=%E2%9C%93&q=language%3Aruby+%22send+%3Aalias_method%22&type=Code
30k+ examples of `send :undef_method` in the wild:
https://github.com/search?utf8=%E2%9C%93&q=language%3Aruby+%22send+%3Aundef_method%22&type=Code
20k+ examples of `send :remove_method` in the wild:
https://github.com/search?utf8=%E2%9C%93&q=language%3Aruby+%22send+%3Aundef_method%22&type=Code




-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>