self, le receveur, et l'envoi de message self, the receiver, and the message send

Même 1 + 2 est un message. Trouve le receveur.Even 1 + 2 is a message. Find the receiver.

Une addition que tout le monde tape le premier jour. Elle n'a rien d'une opération câblée dans le langage : c'est la méthode + appelée sur l'objet 1, avec 2 pour argument. Trois caractères, et tout le modèle de Ruby tient dedans : il n'y a pas de calcul, seulement des objets qui s'envoient des messages.An addition everyone types on day one. It is nothing like an operation wired into the language: it's the method + called on the object 1, with 2 as its argument. Three characters, and all of Ruby's model fits inside: there is no computation, only objects sending each other messages.

1 + 2          # ce que tout le monde écrit
1.+(2)         # ce que Ruby exécute, vraiment
# => 3         # un message + envoyé à l'objet 1, avec 2 en argument

En Java, une fonction existe seule. En Ruby, il n'y en a aucune.In Java, a function stands alone. In Ruby, there are none.

Quand on vient d'un langage statique, « appeler une fonction » et « appeler une méthode » sont deux gestes distincts, et + est un opérateur du langage. Ruby n'a qu'un seul geste : envoyer un message à un objet. Même la fonction que tu crois définir « toute seule » devient une méthode d'un receveur — self, l'objet courant.Coming from a static language, 'calling a function' and 'calling a method' are two distinct gestures, and + is a language operator. Ruby has only one gesture: sending a message to an object. Even the function you think you define 'on its own' becomes a method of a receiver — self, the current object.

// Java : une fonction "libre", attachée à une classe
static int square(int x) { return x * x; }

square(5);        // appel direct : pas de receveur
Math.max(1, 2);   // + est un opérateur primitif, pas une méthode

Deux catégories d'appels coexistent : la fonction qu'on invoque sans receveur, et la méthode sur un objet. Et +, * sont des opérateurs du langage, pas des messages — on ne peut pas les redéfinir.Two call categories coexist: the function you invoke with no receiver, and the method on an object. And +, * are language operators, not messages — you cannot redefine them.

Le point . n'est qu'un raccourci. Dessous : send.The dot . is just shorthand. Underneath: send.

Si tout appel est un envoi, alors le nom de la méthode n'est pas figé dans la syntaxe : c'est une donnée. obj.foo et obj.send(:foo) sont le même geste, et le second laisse choisir le message à l'exécution. Les opérateurs ne sont que du sucre par-dessus ce même envoi — d'où le fait qu'on puisse les définir soi-même.If every call is a send, then the method name isn't frozen into syntax: it's data. obj.foo and obj.send(:foo) are the same gesture, and the second lets you pick the message at runtime. Operators are mere sugar over that same send — which is exactly why you can define them yourself.

"hello".upcase          # => "HELLO"
"hello".send(:upcase)   # => "HELLO" — strictement le même envoi
"hello".send("upcase")  # => "HELLO" — le message peut être nommé à l'exécution

msg = :upcase
"hello".send(msg)       # => "HELLO" — le message est une donnée comme une autre

class Money
  attr_reader :cents
  def initialize(cents) = @cents = cents

  def +(other)                      # on DÉFINIT le message +
    Money.new(@cents + other.cents)
  end

  def to_s = format("%.2f €", @cents / 100.0)
end

Money.new(150) + Money.new(99)   # => 2.49 € — Money#+ a répondu

On n'a pas « surchargé un opérateur » au sens d'un langage statique : on a simplement défini la méthode + sur Money. Quand Ruby voit argent + autre, il envoie le message + à argent — qui, cette fois, sait y répondre.We didn't "overload an operator" in the static-language sense: we simply defined the method + on Money. When Ruby sees money + other, it sends the message + to money — which, this time, knows how to answer.

send n'est pas un bouton « malin ». C'est une clé passe-partout.send is not a "clever" button. It's a master key.

Comprendre que tout est un envoi donne envie de tout passer par send. Mauvais réflexe. send ignore la confidentialité — il ouvre les méthodes privées — et un send piloté par une entrée externe laisse l'utilisateur choisir quel message envoyer. La puissance de l'envoi dynamique se paie : moins d'intention lisible, et une porte grande ouverte si le message vient de dehors.Realizing everything is a send makes you want to route everything through send. Bad reflex. send ignores privacy — it opens private methods — and a send driven by external input lets the user choose which message to send. The power of dynamic dispatch has a price: less readable intent, and a wide-open door if the message comes from outside.

class Account
  def name = "Ada"
  private
  def secret_pin = "4242"
end

acc = Account.new
acc.name                  # => "Ada"
acc.secret_pin            # NoMethodError: private method 'secret_pin'
acc.send(:secret_pin)     # => "4242" — send IGNORE la confidentialité
acc.public_send(:secret_pin) # NoMethodError — public_send la RESPECTE

# Le réflexe "malin" : tout passer par send
user.send(:name)          # … alors que user.name disait la même chose
record.send(:save)        # une indirection gratuite qui masque l'intention

# Le trou de sécurité : un message piloté par l'entrée utilisateur
obj.send(params[:action])      # params[:action] = "destroy_all" ? "send"-icide
                               # send atteint AUSSI les méthodes privées

# Le correctif : public_send + liste blanche explicite
ALLOWED = %i[show index search].freeze
action = params[:action].to_sym
raise ArgumentError unless ALLOWED.include?(action)
obj.public_send(action)        # message calculé, mais borné et public

Un send dont le nom vient de params laisse l'utilisateur appeler n'importe quelle méthode de l'objet, privées comprises. Le correctif n'est pas « ne jamais calculer un message », c'est public_send + une liste blanche : un message dynamique, mais borné et public.A send whose name comes from params lets the user call any method on the object, private ones included. The fix isn't "never compute a message," it's public_send + an allowlist: a dynamic message, but bounded and public.