Référence partagée, ou a = b ne copie rien Shared reference, or a = b copies nothing

a = b ne copie rien. Deux noms, un seul objet.a = b copies nothing. Two names, one object.

Le dev venant de Java, Go ou C lit a = b comme « range dans b une copie de a ». En Ruby, c'est faux : une variable ne tient jamais un objet, elle tient une référence vers lui. a = b fait pointer b vers le même objet que a. Tant qu'on ne réassigne pas, muter l'objet par un nom le mute pour tous les autres — et c'est ainsi qu'un tableau « local » se retrouve modifié à distance par un appelant qu'on avait oublié.A dev from Java, Go or C reads a = b as 'put a copy of a into b'. In Ruby, that's wrong: a variable never holds an object, it holds a reference to one. a = b makes b point at the same object as a. As long as you don't reassign, mutating the object through one name mutates it for all the others — and that's how a 'local' array ends up modified at a distance by a caller you'd forgotten.

a = "ruby"      # un objet String, quelque part en mémoire
b = a           # b ne COPIE rien : b et a désignent le MÊME objet

a << " loop"    # on mute l'objet en place (pas de réassignation)

a               # => "ruby loop"
b               # => "ruby loop"   ← b a changé sans qu'on y touche
a.object_id == b.object_id   # => true   un seul objet, deux noms

Muter en place, c'est modifier l'objet de tous ceux qui le tiennent.Mutating in place modifies the object of everyone who holds it.

Une méthode reçoit un objet en argument et le garde. Si elle le mute en place — un << sur un tableau, un gsub! sur une chaîne — elle ne modifie pas « sa » donnée : elle modifie l'unique objet que l'appelant tient aussi. Le bug ne saute pas aux yeux, car la mutation est correcte de son point de vue ; c'est l'appelant qui, plus tard, retrouve son tableau gonflé sans avoir rien fait. La parade tient en un mot : ne mute pas ce qu'on t'a prêté — copie d'abord, ou produis du neuf.A method receives an object as an argument and keeps it. If it mutates it in place — a << on an array, a gsub! on a string — it isn't modifying 'its' data: it's modifying the single object the caller holds too. The bug isn't obvious, because the mutation is correct from its own point of view; it's the caller who, later, finds their array swollen without having done anything. The remedy is one word: don't mutate what you were lent — copy first, or produce something new.

# La méthode mute l'objet que l'appelant lui a confié
class Cart
  def initialize(items) = @items = items   # on garde la référence reçue
  def add(x) = @items << x                  # << mute en place l'objet de l'appelant
end

list = ["pain"]
cart = Cart.new(list)
cart.add("lait")

list   # => ["pain", "lait"]   ← list a changé sans qu'on la touche
       #    le Cart et l'appelant tiennent le MÊME tableau

@items = items ne copie pas : @items et la variable list de l'appelant désignent le même tableau. Le << dans add le mute en place — donc list grossit aussi. Le Cart croit toucher sa donnée privée ; il touche celle de tout le monde.@items = items doesn't copy: @items and the caller's list variable name the same array. The << in add mutates it in place — so list grows too. The Cart thinks it's touching its private data; it's touching everyone's.

« Même contenu » et « le même objet » sont deux questions différentes."Same contents" and "the same object" are two different questions.

Quand l'aliasing devient un soupçon, Ruby donne de quoi trancher. object_id donne l'identité de chaque objet sous forme de nombre : deux noms qui partagent un object_id désignent le même objet, et muter par l'un se verra par l'autre. Et trois méthodes répondent à trois questions qu'on confond souvent : == compare la valeur, eql? la valeur et le type, equal? l'identité. Savoir laquelle on pose, c'est savoir si on parle de contenu ou d'objet.When aliasing becomes a suspicion, Ruby gives you what you need to settle it. object_id gives each object's identity as a number: two names sharing an object_id name the same object, and mutating through one will be seen through the other. And three methods answer three questions we often conflate: == compares value, eql? value and type, equal? identity. Knowing which one you're asking is knowing whether you're talking about contents or about an object.

a = "ruby"
b = "ruby"        # un SECOND objet, même contenu
c = a             # le MÊME objet que a

a == b            # => true    même contenu (équivalence)
a.equal?(b)       # => false   objets différents (identité)
a.equal?(c)       # => true    un seul et même objet

a.object_id       # => 240     l'identité, sous forme de nombre
b.object_id       # => 260     ← différent : ce n'est pas le même objet
c.object_id       # => 240     ← identique à a

# Trois questions, trois méthodes
a == b            # « même valeur ? »            — surchargeable, le défaut du code
a.eql?(b)         # « même valeur ET même type ? » — le test des clés de Hash
a.equal?(b)       # « le même objet ? »          — l'identité, ne JAMAIS surcharger

1 == 1.0          # => true    même valeur
1.eql?(1.0)       # => false   Integer vs Float : types différents
1.equal?(1.0)     # => false   objets différents

Détail qui éclaire le Vol 1 : certains objets n'ont pas d'identité propre. 1.object_id renvoie toujours le même nombre, partout, parce que les petits Integer, nil, true et false sont des objets immuables et uniques — il n'existe qu'un seul nil dans tout le programme. On ne peut pas les muter, donc l'aliasing sur eux est sans danger. Le piège ne concerne que les objets mutables : String, Array, Hash, et tes propres classes.A detail that lights up Vol 1: some objects have no identity of their own. 1.object_id always returns the same number, everywhere, because small Integers, nil, true and false are immutable, unique objects — there's only one nil in the whole program. You can't mutate them, so aliasing them is harmless. The trap concerns only mutable objects: String, Array, Hash, and your own classes.

Le défaut mutable partagé : un seul tableau pour toutes les instances.The shared mutable default: one array for every instance.

Le contre-exemple emblématique du volume. On donne une valeur par défaut « vide » à un objet — une constante EMPTY = [], un attribut de classe — en croyant offrir à chaque instance son propre conteneur. Mais c'est le même objet, évalué une seule fois, que toutes reçoivent : muter l'une mute la constante, et chaque nouvelle instance naît déjà polluée par les précédentes. L'accumulation est mystérieuse précisément parce que le coupable est invisible : personne n'a « repassé » la donnée, elles partageaient toutes le même tableau depuis le début.The volume's emblematic counter-example. You give an object a default 'empty' value — a constant EMPTY = [], a class-level attribute — believing you're handing each instance its own container. But it's the same object, evaluated once, that all of them receive: mutating one mutates the constant, and each new instance is born already polluted by the previous ones. The accumulation is mysterious precisely because the culprit is invisible: no one 'passed the data along', they all shared the same array from the start.

# Une constante mutable, partagée par TOUTES les instances
class Bucket
  EMPTY = []                       # UN seul tableau, pour tout le programme
  def initialize(items = EMPTY) = @items = items
  def add(x) = @items << x          # << mute EMPTY en place
  def items = @items
end

a = Bucket.new
b = Bucket.new                      # a et b reçoivent le MÊME EMPTY
a.add("pomme")

b.items          # => ["pomme"]   ← b a hérité du "pomme" de a
Bucket::EMPTY    # => ["pomme"]   ← la constante elle-même a gonflé

# Un littéral par appel : chaque instance a son tableau
class Bucket
  def initialize(items = []) = @items = items  # [] réévalué à CHAQUE new
  def add(x) = @items << x
  def items = @items
end

a = Bucket.new
b = Bucket.new                      # deux tableaux distincts
a.add("pomme")

b.items   # => []   ← intact : b n'a jamais partagé le tableau de a