In Ruby, why does BasicObject define __send__ when Kernel already provides send, and when should library code call it?

## Three names, two behaviours Ruby offers three ways to call a method by name: | Method | Defined in | Visibility check | |---|---|---| | `send` | `Kernel` | none: reaches private and protected | | `__send__` | `BasicObject` | none: same behaviour as `send` | | `public_send` | `Kernel` | public methods only | `send` and `__send__` behave the same; CRuby even implements both with the same optimized dispatch. The reason there are two names is **robustness**, not behaviour. The core documentation for `send` says it directly: `__send__` is safer than `send` when the object has its own method called `send`, and it names `Socket` as the example. ## Why a second name is needed `send` is an ordinary English verb, and ordinary method names get reused: - **Sockets.** `BasicSocket#send` and `UDPSocket#send` transmit data. On a socket, `sock.send("hi", 0)` sends bytes over the network; it does not call a method named `hi`. - **Domain classes.** A `Mailer`, `Notification` or `Message` class often defines `send` for its own purpose, overriding `Kernel#send` for its instances. - **Proxies built on `BasicObject`.** `BasicObject` is the minimal root class and does not include `Kernel`, so its subclasses have no `send` and no `public_send`. They do have `__send__`, because `BasicObject` defines it. Generic code, such as a serializer, a test helper, a delegation library or a metaprogramming utility, cannot know which of these objects it will receive. If it writes `obj.send(name)`, it may transmit a datagram or trigger a domain action instead. Writing `obj.__send__(name)` avoids that, because nobody defines `__send__` by accident. ## Ruby protects the underscored name CRuby treats `__send__` as special, alongside `object_id` and `__id__`. Redefining it prints `warning: redefining '__send__' may cause serious problems`, and removing or undefining it prints a similar warning. Library authors rely on that convention: the name is reserved in practice, so a call through it reaches the real dispatcher. ```ruby require "socket" sock = UDPSocket.new sock.send("ping", 0, "127.0.0.1", 9000) # UDPSocket#send: a datagram goes out sock.__send__(:closed?) # dynamic call to IO#closed? => false class Proxy < BasicObject def initialize(target) = @target = target def method_missing(name, *args, &block) @target.__send__(name, *args, &block) end def respond_to_missing?(name, include_private = false) = true end ``` Inside `Proxy`, calling `send` on the proxy itself would not reach `Kernel#send` (there is none); it would fall into the proxy's own `method_missing`. ## What __send__ does not change 1. **It does not add a visibility check.** Like `send`, it reaches private methods. There is no underscored twin of `public_send`, so generic code that must respect visibility calls `public_send` and accepts that a class could, in principle, override it. 2. **It is not faster.** Both names go through the same dispatch path. 3. **It is not a different lookup.** The target is found through the normal method lookup, and `method_missing` runs for unknown names in both cases. ## A quick way to remember it - `send` — a common verb; any class may take it for itself. - `__send__` — the same dispatcher under a reserved-looking name, defined on the root class. - `public_send` — the dispatcher with a visibility check, defined next to `send` in `Kernel`. When you write code that receives arbitrary objects, reach for the name that cannot have been taken: `__send__` when private access is acceptable, `public_send` when it is not and the objects are ordinary `Object` descendants. ## Style in application code In everyday application code, `public_send` is the usual choice and `send` appears where private access is intended. RuboCop has a `Style/Send` cop that prefers `__send__` or `public_send` over `send`, on the grounds that `send` may overlap with existing methods; it is disabled by default, so a team switches it on only if it wants that rule. Library code that dispatches on objects it does not control is where `__send__` earns its underscores. ## What an interviewer is listening for The key sentence is: `__send__` exists because `send` is a common name that classes override, and because `BasicObject` subclasses have no `Kernel#send` at all. A good answer adds that `__send__` still bypasses visibility, so it is a robustness choice, not a safety one.