# Wildcard and broadcast overrides **🟠 Advanced · Lesson 19** THE OTHER TWO OVERRIDE FORMS. Lesson 01 taught the PATH form - "transport>credentials" - which names a socket exactly. There are three targeting forms in total, and melder states all of them: PATH a>b>c name the socket exactly UNIQUE *param "there is exactly one of these, find it" BROADCAST **param "hit every one" You still pass a plain dict to meld(override=...). The grammar lives in the KEY. WHY THE OTHER TWO EXIST A path requires you to know the shape of a graph you did not build. `*credentials` says "somewhere below this root there is exactly one credentials socket - I do not care where". `**credentials` says "there may be several and I mean all of them". AND HERE IS THE PART THAT MAKES THEM SAFE TO USE. THE MATCH COUNTS ARE ENFORCED, NOT ADVISORY. *param requires EXACTLY ONE match **param requires AT LEAST ONE match Miss the count and resolution REFUSES. It does not apply your override to the first thing it found, and it does not quietly do nothing. melder's own reasoning, which is worth reading twice: "a `*param` that silently matched three sockets, or zero, would apply the caller's intent to the wrong object or to nothing at all, and BOTH FAIL INVISIBLY AT RUNTIME rather than at resolution. Failing loudly at map time is the whole point of resolving specs up front instead of during construction." That is the never-substitute rule (lessons 06/11/12/15/16) applied to targeting. A wildcard that guessed would be the worst kind of bug: your fixture lands on the wrong object and everything appears to work. PRECEDENCE A `**param` broadcast and an exact `a>b>c` path can both name the same socket. When they overlap, specificity decides - the exact path wins over the broadcast. Being more specific means being more authoritative, which is the only ordering that would not surprise someone. THE LIFETIME RULE STILL APPLIES (lesson 01's sharp edge) An override is surgical in WHERE it reaches, not in HOW LONG it lasts. Override into `unique` and you have changed the world. Everything below is bound `many` so each meld builds its own graph and the fixtures cannot escape the call. ## Before you run Use the [Advanced guide](../../advanced/index.md) for prerequisite concepts. Run from a checkout with Melder installed and Python 3.14 free-threading selected. The collection download includes the level's local helper modules. ## Run the saved script ```bash python UX_and_AIX_experiences/03_advanced/19_wildcard_and_broadcast_overrides.py ``` ```powershell py -3.14t UX_and_AIX_experiences/03_advanced/19_wildcard_and_broadcast_overrides.py ``` {download}`Download this collection <../../downloads/advanced-examples.zip>` · [Source on GitHub](https://github.com/Synaptic724/melder/blob/4b364a338debcb1c010d0f6e9dcbbabb62945ba0/UX_and_AIX_experiences/03_advanced/19_wildcard_and_broadcast_overrides.py) ## Public surface meld(override={"*param": obj}) and {"**param": obj} ## Code ```{literalinclude} ../../downloads/03_advanced/19_wildcard_and_broadcast_overrides.py :language: python :linenos: ``` ## Check the outcome The script contains its own assertions or demonstrated refusal paths. Run it to evaluate those checks against your installed version. The code above is taken directly from the saved file; no run output is invented here. [More advanced examples](index.md) · [Level guide](../../advanced/index.md) ## Related guides - [Deep, wildcard, and broadcast overrides](../../advanced/overrides.md)