L'objet Method, ou pourquoi on ne le passe pas The Method object, and why you don't pass it

Une méthode n'est pas une valeur — il faut la demander.A method isn't a value — you have to ask for one.

Le Vol 6 manipule classes et méthodes à l'exécution ; ce numéro part de la plus discrète de ces manipulations. Contrairement à JavaScript ou Python, en Ruby une méthode n'est pas un objet de première classe : la définir ne te rend aucune valeur transportable, et écrire son nom seul lève une NameError. Tu peux pourtant réifier une méthode — en demander un objet, via obj.method(:nom). Tu obtiens un Method, qu'on appelle avec .call exactement comme un proc ou une lambda. Mais pourquoi cette étape de plus ? Pourquoi les méthodes ne sont-elles pas first-class d'office ? Parce que Ruby, langage purement objet dans la lignée de Smalltalk, sépare une chose qu'on confond presque toujours : la méthode et le message.Vol 6 manipulates classes and methods at runtime; this issue starts from the quietest of those manipulations. Unlike JavaScript or Python, in Ruby a method is not a first-class object: defining it hands you no value to carry, and writing its name alone raises a NameError. You can still reify a method — ask for an object representing it, via obj.method(:name). You get a Method, called with .call exactly like a proc or a lambda. But why this extra step? Why aren't methods first-class out of the box? Because Ruby, a purely object-oriented language in the Smalltalk lineage, separates a thing we almost always conflate: the method and the message.

class Greeter
  def hello(name) = "Bonjour, #{name}"
end

g = Greeter.new
g.hello("Ada")          # => "Bonjour, Ada"   un message hello envoyé à g
hello                   # NameError : aucune valeur libre nommée hello
                        #   ↑ définir une méthode ne crée AUCUN objet à passer

m = g.method(:hello)    # on DEMANDE un objet qui représente la méthode
m.class                 # => Method
m.call("Ada")           # => "Bonjour, Ada"   appelable comme un proc/lambda
m.owner                 # => Greeter          d'où vient l'implémentation

Le handle ressemble à un lien vivant — c'est une photo.The handle looks like a live link — it's a photograph.

On croit qu'un objet Method est une poignée branchée en permanence sur l'objet, qui suivrait ses évolutions. Faux : il fige l'implémentation résolue à l'instant de la capture. Enrichis l'objet juste après — un extend, un module qui redéfinit notify — et le handle, lui, ne bouge pas : il appelle toujours l'ancienne méthode, son owner reste UI. Envoie au contraire le message notify à l'objet, et tu obtiens à chaque fois la version la plus à jour, parce que l'envoi de message refait la résolution le long de la chaîne d'ancêtres. Le même appel, deux temporalités : la photo et la question reposée.You'd think a Method object is a handle permanently wired into the object, tracking its changes. Wrong: it freezes the implementation resolved at the instant of capture. Enrich the object right after — an extend, a module redefining notify — and the handle doesn't budge: it still calls the old method, its owner stays UI. Send the notify message to the object instead, and every time you get the most up-to-date version, because a message send redoes the lookup along the ancestor chain. The same call, two timelines: the photo and the question re-asked.

module Bell
  def notify(msg)
    super
    puts "beep"
  end
end

class UI
  def notify(msg) = puts(msg)
end

ui = UI.new
saved = ui.method(:notify)   # capture l'implémentation ACTUELLE
ui.extend(Bell)              # on enrichit l'objet APRÈS la capture

saved.call("thé prêt")       # "thé prêt"            ← pas de beep : figé
saved.owner                  # => UI    le handle pointe l'ancienne méthode

saved a été créé avant le extend : il a figé UI#notify, et rien ne le rattachera à Bell#notify. Son owner le trahit — il reste UI. C'est exactement le genre de référence qui « se périme » entre le moment où on la stocke et le moment où on l'exécute.saved was created before the extend: it froze UI#notify, and nothing will rebind it to Bell#notify. Its owner gives it away — it stays UI. This is exactly the kind of reference that "goes stale" between the moment you store it and the moment you run it.

Le Method résout une fois ; le message résout à chaque envoi.A Method resolves once; a message resolves on every send.

obj.method(:m) renvoie un Method qui mémorise deux choses : son receveur (l'objet), et son owner (la classe ou le module exact d'où vient le code, résolu une seule fois le long de la chaîne d'ancêtres). De là, unbind donne une UnboundMethod détachable, et to_proc un Proc — c'est pourquoi &obj.method(:m) se passe en bloc. Mais ce confort cache le mécanisme : la capture a fait la recherche une fois pour toutes. Un envoi de message, lui, refait cette recherche à chaque appel — c'est le late binding. Conséquence directe : réécris la méthode, extend ou prepend l'objet après la capture, et le message suit pendant que le handle reste figé.obj.method(:m) returns a Method that remembers two things: its receiver (the object), and its owner (the exact class or module the code comes from, resolved once along the ancestor chain). From there, unbind gives a detachable UnboundMethod, and to_proc a Proc — which is why &obj.method(:m) passes as a block. But that convenience hides the mechanism: capture did the lookup once and for all. A message send instead redoes that lookup on every call — that's late binding. Direct consequence: rewrite the method, extend or prepend the object after capture, and the message follows while the handle stays frozen.

m = g.method(:hello)   # Method : LIÉ à g, RÉSOLU vers Greeter#hello
m.receiver             # => g          le destinataire fixé
m.owner                # => Greeter    la classe d'où sort l'implémentation
m.unbind               # => UnboundMethod : la méthode sans receveur
m.to_proc              # => Proc       d'où &g.method(:hello) marche en bloc

["Ada", "Bo"].map(&g.method(:hello))   # capture figée passée en bloc
["Ada", "Bo"].map { |n| g.hello(n) }   # message ré-envoyé à chaque tour

g = Greeter.new
m = g.method(:hello)   # on fige la résolution maintenant

class Greeter          # classes ouvertes (Vol 6 № 3) : on réécrit la méthode
  def hello(name) = "Salut, #{name}"
end

g.hello("Ada")   # => "Salut, Ada"     le message voit la nouvelle définition
m.call("Ada")    # => "Bonjour, Ada"   le handle a figé l'ancienne

class UI
  original = instance_method(:notify)  # UnboundMethod : on fige EXPRÈS

  define_method(:notify) do |msg|      # № 2 — define_method ferme sur original
    puts "[log] notify"
    original.bind(self).call(msg)      # l'ancienne implémentation, préservée
  end
end

UI.new.notify("thé prêt")   # "[log] notify" puis "thé prêt"
# le message ne peut PLUS atteindre l'ancienne version :
# seul le handle capturé l'a gardée — l'instantané était le but

Voilà l'usage légitime que promettait le cadrage — et il convoque tout le Vol 6. On capture l'originale précisément parce qu'on va la rendre inatteignable : la redéfinition (classes ouvertes, № 3) va masquer UI#notify, et define_method (№ 2) referme sa closure sur le handle qui, seul, la préserve. C'est la mécanique des espions de test et de l'instrumentation : geler une réponse n'est plus un accident temporel, c'est le contrat.Here is the legitimate use the framing promised — and it summons the whole of Vol 6. You capture the original precisely because you're about to make it unreachable: the redefinition (open classes, № 3) will shadow UI#notify, and define_method (№ 2) closes over the handle that alone preserves it. That's the mechanics of test spies and instrumentation: freezing an answer is no longer a temporal accident, it's the contract.

Dernier révélateur de la frontière : obj.method(:m) exige une méthode résolue. Sur une méthode fantôme servie par method_missing (№ 1), il lève NameError tant que respond_to_missing? ne l'annonce pas — le message, lui, se contente d'une responsabilité. Retiens donc : un Method object est le bon outil quand tu veux précisément un instantané — une réponse gelée, indépendante de l'évolution future de l'objet. Dès que tu veux le comportement courant d'un collaborateur, passe l'objet et envoie-lui le message. Le chapitre suivant montre ce qui arrive quand on confond les deux.One last marker of the boundary: obj.method(:m) demands a resolved method. On a ghost method served by method_missing (№ 1), it raises NameError until respond_to_missing? declares it — the message, meanwhile, settles for a responsibility. So keep this: a Method object is the right tool when you specifically want a snapshot — a frozen answer, independent of the object's future evolution. The moment you want a collaborator's current behavior, pass the object and send it the message. The next chapter shows what happens when you confuse the two.

Câbler un collaborateur par obj.method(:m) : le beep disparaît.Wiring a collaborator via obj.method(:m): the beep vanishes.

Le contre-exemple obligatoire du numéro, tiré d'une vraie injection de dépendances. Une TeaClock relie un minuteur à une UI : le minuteur veut juste un objet à prévenir quand le thé est prêt, sans savoir comment l'alerte est rendue. On lui injecte donc @ui.method(:notify) — un callable, propre en apparence. Puis la clock initialise ses plugins, dont l'un extend l'UI pour ajouter un beep. On lance… et pas de beep. Le minuteur tient un Method capturé AVANT le plugin : il appelle l'ancienne implémentation. C'est un couplage temporel — la référence a été figée trop tôt. La correction : passer l'objet UI lui-même et lui envoyer le message notify. Le minuteur obtient alors le comportement courant, plugin compris.The issue's mandatory counter-example, drawn from real dependency injection. A TeaClock wires a timer to a UI: the timer just wants an object to alert when the tea is ready, without knowing how the alert is rendered. So we inject @ui.method(:notify) — a callable, clean on the surface. Then the clock initializes its plugins, one of which extends the UI to add a beep. We run it… and no beep. The timer holds a Method captured BEFORE the plugin: it calls the old implementation. That's a temporal coupling — the reference was frozen too early. The fix: pass the UI object itself and send it the notify message. The timer then gets the current behavior, plugin included.

# Bell : le module « beep » du ch. 02 — StdoutUI : l'équivalent de son UI

class SleepTimer            # le rôle « minuteur » : attendre, puis alerter
  def initialize(seconds, notifier)
    @seconds, @notifier = seconds, notifier
  end
  def start
    sleep(@seconds)
    @notifier.call("Le thé est prêt")     # appelle un callable FIGÉ
  end
end

module Plugins
  class BellPlugin
    def initialize(clock) = clock.ui.extend(Bell)   # enrichit l'UI au démarrage
  end
end

class TeaClock
  attr_reader :ui
  def initialize(seconds)
    @ui = StdoutUI.new
    @timer = SleepTimer.new(seconds, @ui.method(:notify))  # capture AVANT plugins
    Plugins.constants.each { |c| Plugins.const_get(c).new(self) }
  end
  def start = @timer.start
end

TeaClock.new(0.5).start    # "Le thé est prêt"   ← où est passé le beep ?

class SleepTimer
  def start
    sleep(@seconds)
    @notifier.notify("Le thé est prêt")   # ENVOIE le message, ré-résolu
  end
end

class TeaClock
  def initialize(seconds)
    @ui = StdoutUI.new
    @timer = SleepTimer.new(seconds, @ui)   # on passe l'OBJET, pas un handle
    Plugins.constants.each { |c| Plugins.const_get(c).new(self) }
  end
  def start = @timer.start
end

TeaClock.new(0.5).start    # "Le thé est prêt" / "beep"   ← le plugin est vu