freeze, ou rendre la mutation impossible freeze, or making mutation impossible

L'autre réponse au partage : rendre l'objet impossible à muter.The other answer to sharing: make the object impossible to mutate.

Le numéro précédent montrait le danger : muter un objet partagé surprend tous ceux qui le tiennent. La parade y était « copie avant de muter ». freeze prend le problème par l'autre bout : au lieu de multiplier les copies, on gèle l'objet une fois pour toutes. Un objet gelé refuse toute mutation — un << ou un gsub! lève FrozenError au lieu de modifier en silence. Et si l'objet ne peut plus changer, le partager redevient parfaitement sûr : l'immutabilité, c'est l'aliasing sans le piège.The previous issue showed the danger: mutating a shared object surprises everyone who holds it. The remedy there was 'copy before mutating'. freeze takes the problem from the other end: instead of multiplying copies, you freeze the object once and for all. A frozen object refuses every mutation — a << or a gsub! raises FrozenError instead of modifying silently. And if the object can no longer change, sharing it becomes perfectly safe again: immutability is aliasing without the trap.

a = "ruby".freeze   # on gèle l'objet : la mutation devient impossible
b = a               # b et a désignent toujours le MÊME objet

a << " loop"
# FrozenError: can't modify frozen String: "ruby"
#   ↑ la mutation est REFUSÉE, pas silencieuse

a.frozen?   # => true
b.frozen?   # => true   un objet est gelé, pas une variable

Une ligne de commentaire qui gèle toutes les chaînes du fichier.One comment line that freezes every string in the file.

Par défaut, chaque littéral de chaîne est un objet mutable, et réalloué à chaque évaluation — un coût qu'on paie sans le voir dans les boucles chaudes. Le commentaire magique # frozen_string_literal: true, en tête de fichier, change la donne : tous les littéraux de chaîne deviennent gelés ET partagés (un seul objet réutilisé). On gagne en allocations et en sûreté ; en échange, le code qui mutait un littéral lève maintenant FrozenError. La parade quand on a vraiment besoin d'une chaîne mutable : le + unaire, +"…", qui en redonne une copie libre.By default, every string literal is a mutable object, reallocated on each evaluation — a cost you pay unseen in hot loops. The magic comment # frozen_string_literal: true, at the top of the file, changes that: all string literals become frozen AND shared (one object reused). You gain on allocations and safety; in exchange, code that mutated a literal now raises FrozenError. The remedy when you genuinely need a mutable string: the unary +, +"…", which hands back a free copy.

# Sans le commentaire magique (le défaut) : chaque littéral est MUTABLE
"ruby".frozen?        # => false

# et chaque "ruby" du fichier est un NOUVEL objet, réalloué à chaque passage
def tag = "ruby"
tag.object_id == tag.object_id   # => false   deux objets distincts
                                 #   une allocation à chaque appel

Chaque "ruby" du fichier crée un objet neuf, à chaque évaluation — pratique si on veut le muter ensuite, coûteux si on ne le mute jamais. Dans une méthode appelée des milliers de fois, c'est des milliers d'allocations pour une chaîne qu'on ne fait que lire.Each "ruby" in the file creates a fresh object, on every evaluation — handy if you mean to mutate it, costly if you never do. In a method called thousands of times, that's thousands of allocations for a string you only read.

freeze retourne l'objet, et ne gèle qu'un seul niveau.freeze returns the object, and freezes one level only.

Deux faits à connaître pour s'en servir juste. D'abord, freeze retourne l'objet lui-même — donc on l'enchaîne (CONST = [...].freeze), et frozen? répond à la question. Certains objets sont d'ailleurs gelés par nature : les Symbol, les Integer, nil, true et false sont immuables d'office, ce qui explique pourquoi les partager n'a jamais posé problème. Ensuite — et c'est le piège du prochain chapitre — freeze est superficiel : geler un tableau empêche d'y ajouter un élément, mais ne gèle pas les éléments déjà dedans.Two facts to use it well. First, freeze returns the object itself — so you chain it (CONST = [...].freeze), and frozen? answers the question. Some objects are frozen by nature anyway: Symbols, Integers, nil, true and false are immutable out of the box, which is why sharing them never caused trouble. Second — and it's the next chapter's trap — freeze is shallow: freezing an array stops you adding an element, but doesn't freeze the elements already inside.

s = "ruby"
s.freeze          # => "ruby"   freeze RETOURNE l'objet (chaînable)
s.frozen?         # => true

# certains objets sont gelés par nature — immuables d'office
:ruby.frozen?     # => true   les Symbol, toujours
1.frozen?         # => true   les Integer, Float, nil, true, false
"ruby".frozen?    # => false  un littéral String, lui, est mutable (par défaut)

# freeze est SUPERFICIEL : il gèle l'objet, pas son contenu
config = ["ruby"].freeze   # le tableau est gelé…
config << "loop"
# FrozenError: can't modify frozen Array

config[0] << " loop"       # …mais l'élément, lui, n'est PAS gelé
config[0]                  # => "ruby loop"   le contenu a bel et bien changé

# pour geler en profondeur, il faut geler chaque niveau soi-même
config.each(&:freeze)      # gèle aussi les éléments

Ce caractère superficiel n'est pas un défaut, c'est le pendant exact du dup du prochain numéro : freeze gèle un niveau, dup copie un niveau. Les deux opérations s'arrêtent à la première couche et laissent le contenu imbriqué tel quel. Retenir l'un, c'est déjà comprendre l'autre.This shallowness isn't a flaw, it's the exact mirror of the next issue's dup: freeze freezes one level, dup copies one level. Both operations stop at the first layer and leave the nested contents as they are. Grasp one and you already understand the other.

Le .freeze qui ment : gelé en surface, partagé en profondeur.The .freeze that lies: frozen on top, shared underneath.

Le contre-exemple emblématique du numéro. On gèle une constante de configuration et on la croit, dès lors, sûre à partager partout. Mais freeze étant superficiel, ses valeurs imbriquées — un Array de tags, un Hash d'options — restent mutables et partagées. Muter l'une depuis n'importe où mute la constante elle-même, exactement le piège du № 1 — sauf qu'ici le .freeze a endormi la méfiance : on a vu le mot « frozen » et on a cessé de se demander qui d'autre tenait ce tableau. Le faux sentiment de sécurité coûte plus cher que pas de freeze du tout.The issue's emblematic counter-example. You freeze a configuration constant and, from then on, believe it safe to share everywhere. But freeze being shallow, its nested values — an Array of tags, a Hash of options — stay mutable and shared. Mutating one from anywhere mutates the constant itself, exactly the № 1 trap — except here the .freeze lulled your suspicion: you saw the word 'frozen' and stopped asking who else held that array. The false sense of security costs more than no freeze at all.

# Une constante "gelée" qu'on croit donc sûre à partager
DEFAULTS = { tags: [], locale: "fr" }.freeze   # le Hash est gelé…

def build(opts = DEFAULTS)
  opts[:tags] << "new"   # …mais :tags est un Array NON gelé, partagé
  opts
end

build   # => { tags: ["new"], locale: "fr" }
build   # => { tags: ["new", "new"], locale: "fr" }
        #   ↑ DEFAULTS[:tags] gonfle : le .freeze a MENTI sur la sûreté

# Option A — geler en profondeur : plus rien n'est mutable
DEFAULTS = { tags: [].freeze, locale: "fr" }.freeze
DEFAULTS[:tags] << "new"
# FrozenError: can't modify frozen Array   ← l'erreur naît à la faute

# Option B — ne jamais muter le partagé : produire du neuf
def build(opts = DEFAULTS)
  { **opts, tags: opts[:tags] + ["new"] }   # + crée un nouvel Array
end                                          # DEFAULTS reste intact