method_missing, ou répondre à ce qu'on n'a pas écrit method_missing, or answering what you never wrote

method_missing est ce qui s'exécute au bout de la chaîne.method_missing is what runs at the end of the chain.

Le Vol 6 ouvre la métaprogrammation — du code qui écrit du code — et on y entre par prudence, pas par éblouissement. Premier outil, et le plus exposé à l'abus : method_missing. Le Vol 5 a montré qu'un message parcourt la chaîne d'ancêtres jusqu'au premier qui répond. Mais que se passe-t-il quand personne ne répond ? Ruby ne lève pas tout de suite : il envoie un dernier message, method_missing, tout au bout de la chaîne. Par défaut, BasicObject#method_missing lève le NoMethodError qu'on connaît. Le redéfinir, c'est intercepter les messages inconnus avant l'erreur — répondre à des méthodes qu'on n'a jamais écrites.Vol 6 opens metaprogramming — code that writes code — and we enter through caution, not dazzle. First tool, and the most abuse-prone: method_missing. Vol 5 showed a message walks the ancestor chain to the first that answers. But what happens when no one answers? Ruby doesn't raise right away: it sends one last message, method_missing, at the very end of the chain. By default, BasicObject#method_missing raises the NoMethodError we know. Redefining it intercepts unknown messages before the error — answering methods you never wrote.

"abc".wat
# NoMethodError: undefined method 'wat' for an instance of String
#   ↑ Ruby a parcouru TOUTE la chaîne d'ancêtres (Vol 5), rien n'a répondu —
#     alors il appelle method_missing au bout, qui par défaut lève l'erreur

class Ghost
  def method_missing(name, *args, &block)   # on intercepte AVANT l'erreur
    "tu as appelé #{name} avec #{args.inspect}"
  end
end

Ghost.new.anything(1, 2)   # => "tu as appelé anything avec [1, 2]"
Ghost.new.wat              # => "tu as appelé wat avec []"

Sans son jumeau, l'objet répond mais jure qu'il ne sait pas.Without its twin, the object answers but swears it can't.

method_missing seul crée un objet schizophrène : il exécute c.host sans broncher, mais c.respond_to?(:host) répond false. Pourquoi ? Parce que respond_to? consulte les méthodes réellement définies, et host n'en est pas une — elle est interceptée. L'objet ment au duck typing du Vol 3 : tout le code qui demande « sais-tu faire X ? » avant d'appeler X le rejette à tort. respond_to_missing? est le correctif obligatoire : il déclare quels messages interceptés l'objet honore vraiment, et répare du même coup respond_to?, method, la délégation — toute la machinerie qui s'appuie dessus.method_missing alone makes a schizophrenic object: it runs c.host without blinking, but c.respond_to?(:host) returns false. Why? Because respond_to? consults the actually-defined methods, and host isn't one — it's intercepted. The object lies to Vol 3's duck typing: any code asking 'can you do X?' before calling X wrongly rejects it. respond_to_missing? is the mandatory fix: it declares which intercepted messages the object truly honors, and repairs respond_to?, method, delegation — the whole machinery that relies on it.

class Config
  def initialize(data) = @data = data
  def method_missing(name, *args)
    @data.fetch(name) { super }      # répond aux clés connues, sinon NoMethodError
  end
end

c = Config.new(host: "localhost", port: 5432)
c.host                  # => "localhost"   ça MARCHE
c.port                  # => 5432

c.respond_to?(:host)    # => false   ← MENSONGE : l'objet répond pourtant
[c].select { |x| x.respond_to?(:host) }   # => []   le duck typing (Vol 3) cassé
c.method(:host)         # NameError: undefined method 'host'   ← method() ment aussi

L'objet « marche » en apparence, et c'est le piège : tout le code défensif qui interroge respond_to? avant d'appeler — sérialiseurs, formulaires, case sur capacités — le traite comme s'il ne savait rien faire. method(:host) échoue aussi, et un SimpleDelegator qui l'enveloppe refuse de transmettre host. Seul &:host passe — il envoie le message sans rien demander. L'objet vit à moitié hors du protocole.The object "works" on the surface, and that's the trap: all the defensive code querying respond_to? before calling — serializers, forms, capability cases — treats it as if it could do nothing. method(:host) fails too, and a SimpleDelegator wrapping it refuses to forward host. Only &:host gets through — it sends the message without asking anything. The object lives half outside the protocol.

Toujours rendre la main par super — et le cas qui le justifie.Always hand back via super — and the case that justifies it.

method_missing reçoit le nom du message, ses arguments et son bloc. La règle d'or : ne traiter que ce qu'on revendique, et appeler super pour tout le reste — sinon on avale silencieusement chaque faute de frappe, et le NoMethodError disparaît. Le couple complet appelle donc super des deux côtés : dans method_missing pour lever proprement, dans respond_to_missing? pour déléguer la question. Le cas où tout cela est légitime, plutôt que paresseux : le proxy. Un objet dont on ne peut PAS connaître les méthodes à l'avance, parce qu'il enveloppe une cible quelconque — là, method_missing est le bon outil, pas un raccourci.method_missing receives the message name, its arguments and its block. The golden rule: handle only what you claim, and call super for everything else — otherwise you silently swallow every typo, and the NoMethodError vanishes. The full pair therefore calls super on both sides: in method_missing to raise cleanly, in respond_to_missing? to delegate the question. The case where all this is legitimate, rather than lazy: the proxy. An object whose methods you CAN'T know in advance, because it wraps an arbitrary target — there, method_missing is the right tool, not a shortcut.

def method_missing(name, *args, &block)
  #   name  : le Symbol du message reçu (:host)
  #   args  : les arguments positionnels
  #   block : le bloc éventuel
  if intercepte?(name)
    repond(name, *args, &block)
  else
    super              # ESSENTIEL : rend la main → vrai NoMethodError
  end
end

# Le cas légitime : un proxy qui délègue à une cible quelconque
class Proxy
  def initialize(target) = @target = target

  def method_missing(name, *args, &block)
    if @target.respond_to?(name)
      @target.public_send(name, *args, &block)   # on fait suivre
    else
      super                                       # sinon, erreur honnête
    end
  end

  def respond_to_missing?(name, include_private = false)
    @target.respond_to?(name, include_private) || super
  end
end

Proxy.new([1, 2, 3]).map { |x| x * 2 }   # => [2, 4, 6]   délégué à l'Array

Retiens la frontière : method_missing est pour l'ensemble ouvert et imprévisible (un proxy, un client d'API dont les champs viennent du serveur). Dès que l'ensemble des messages est connu et fini — cinq champs, dix accesseurs — il n'a plus rien à y faire : c'est le terrain du prochain chapitre, et de define_method.Keep the boundary: method_missing is for the open, unpredictable set (a proxy, an API client whose fields come from the server). The moment the message set is known and finite — five fields, ten accessors — it has no business there: that's the next chapter's ground, and define_method's.

Six tests, un objet à écrire. Les trois premiers tombent avec le method_missing qu'on écrit tous du premier coup. Les trois suivants sont ceux du numéro : ils ne demandent rien d'exotique — juste que respond_to? dise la vérité, que method(:…) rende quelque chose d'appelable, et qu'un code poli qui demande avant d'envoyer passe par votre proxy au lieu de le contourner sans bruit. Vous saurez que le jumeau est obligatoire quand vous aurez vu vos trois lignes rouges, pas avant.Six tests, one object to write. The first three fall to the method_missing we all write on the first try. The last three are the issue's: they ask for nothing exotic — only that respond_to? tell the truth, that method(:…) return something callable, and that polite code which asks before sending goes through your proxy instead of silently around it. You'll know the twin is mandatory once you've seen your three red lines, not before.

method_missing pour un ensemble connu : de la magie inutile.method_missing for a known set: pointless magic.

Le contre-exemple obligatoire du numéro. On a cinq champs connus à l'avance, et on dégaine method_missing « pour ne pas écrire cinq accesseurs ». Mais ici l'ensemble est fini et nommable : intercepter au lieu de définir ne fait que cacher. Les méthodes n'apparaissent dans aucune introspection, un grep host ne les trouve pas, chaque appel fait un détour par method_missing, les stack traces deviennent cryptiques, et on doit maintenir le couple à la main. define_method dans une boucle génère exactement ces cinq méthodes — réelles, listables, grep-ables — et respond_to? marche tout seul. La règle : method_missing pour l'ouvert, define_method pour le connu.The issue's mandatory counter-example. You have five fields known in advance, and you reach for method_missing 'to avoid writing five accessors'. But here the set is finite and nameable: intercepting instead of defining only hides. The methods show in no introspection, a grep host won't find them, every call detours through method_missing, stack traces turn cryptic, and you maintain the pair by hand. define_method in a loop generates exactly those five methods — real, listable, grep-able — and respond_to? works on its own. The rule: method_missing for the open, define_method for the known.

# Le piège : method_missing pour 5 champs CONNUS d'avance
class Settings
  FIELDS = %i[host port user pass ssl]
  def initialize(h) = @h = h

  def method_missing(name, *args)
    FIELDS.include?(name) ? @h[name] : super
  end
  def respond_to_missing?(name, priv = false)
    FIELDS.include?(name) || super
  end
end

Settings.instance_methods(false)   # => [:method_missing]
# la seule méthode exposée est l'intercepteur : aucun :host, :port…
# $ grep "def host" .              → rien : introuvable
# coût : un détour par method_missing à CHAQUE appel, des stack traces
# cryptiques, et le couple à gérer à la main — pour 5 noms qu'on connaît

# define_method : on génère de VRAIES méthodes, en boucle
class Settings
  FIELDS = %i[host port user pass ssl]
  def initialize(h) = @h = h

  FIELDS.each do |field|
    define_method(field) { @h[field] }   # une vraie méthode par champ
  end
end

Settings.instance_methods(false).sort        # => [:host, :pass, :port, :ssl, :user]
Settings.new(host: "x").respond_to?(:host)   # => true   sans rien de plus
# (.sort : instance_methods ne garantit aucun ordre de retour)
# traçable, listable, respond_to? marche seul, zéro détour à l'appel