Renaming to collisions: how Nebula reuses one name across members, and why the CLR tells them apart by signature
DEV Community
Renaming to collisions: how Nebula reuses one name across members, and why the CLR tells them apart by signature
A naive renamer gives every member a unique short name — a, b, c, d — and stops there. It is leaving value on the table, because .NET does not identify a member by its name. A method is identified by its name together with its signature, a field by its name and its declaring type, and the runtime binds every call through a metadata token resolved at load time, not by re-matching strings. That means you can rename dozens of unrelated methods to the single name a, so long as their signatures differ, and the assembly still loads, verifies and runs. This post reads the MethodDef and String heap metadata to show why collision renaming is legal, walks the exact rules that bound it — same-signature clashes, virtual override chains, explicit interface implementations — and explains how Nebula packs names down to a tiny reused set that both shrinks the string heap and turns a decompiler’s output into an unreadable wall of identically named members.
0 comments
No comments yet.