A runtime type test -- Python's isinstance, a Go type assertion on an interface, JavaScript's instanceof -- appears to ask the same question of an object. What is each one actually checking, and where do they give different answers for objects of the same shape?

## What a type test is, formally Asking "is this object an X?" is asking whether the object's type belongs to a set. Languages define that set three different ways, and the definitions do not coincide. 1. **Declared ancestry (nominal).** X is a node in a hierarchy the programmer wrote down; membership is reachability in that declared partial order. This is the model most people assume by default. 2. **Structural capability.** X is a predicate over the type's signature -- "has these methods with these types". Membership is computed, not declared, and any type that happens to satisfy the predicate is in the set forever, including types written before X existed. 3. **Registered conformance.** X keeps a side table of types that count as members regardless of where they sit in the hierarchy. Membership is neither declared in the type nor derived from its shape; it is asserted by a third party. ## Python: nominal, until the metaclass says otherwise `isinstance(obj, C)` normally checks `type(obj)`'s MRO. But the check is a protocol: `type(C).__instancecheck__(C, obj)` runs first. `abc.ABCMeta` implements it against a registry, so `MyBuffer` can be registered with an abstract base and answer `True` to `isinstance` while having no inheritance link whatsoever. Nothing else changes -- attribute lookup, `super()`, and the MRO are untouched, and none of the abstract base's default methods are inherited. This is the sharpest illustration that a type test's answer and the object's actual capabilities are separate facts. ## Go: structural, checked at runtime over method sets Go has interfaces but no `implements`. A type satisfies `io.Reader` when it has `Read([]byte) (int, error)`, and the assertion `x.(io.Reader)` checks that at runtime against the value's dynamic type descriptor. Two consequences follow. First, a type can satisfy an interface defined in a package it has never heard of, which is why Go code declares interfaces at the *consumer*. Second, satisfaction can be gained by accident: add a method with the right name and signature for unrelated reasons, and the type silently becomes a member of every interface that predicate matches. Pointer receivers add a wrinkle -- the method set of `T` and of `*T` differ, so the same underlying type answers differently depending on whether you hold a value or a pointer. ## JavaScript: identity of one constructor's prototype object `x instanceof C` walks x's prototype chain looking for the exact object `C.prototype`. It is an identity comparison, not a shape or name comparison. Load the same class twice -- an iframe, a Node `vm` context, two copies of a library in a dependency tree -- and you get two distinct `C.prototype` objects, so an array built in one realm is not `instanceof Array` in the other even though it is unquestionably an array. The standard library's answer is `Array.isArray`, which asks the internal slot instead; `Symbol.hasInstance` lets a class override `instanceof` outright, making the test whatever the author wants. ## TypeScript and Rust: nothing to test TypeScript's types are structural but exist only at compile time, so at runtime nothing remains to interrogate -- hence user-defined type guards (`function isDuck(x): x is Duck`) that hand-write the predicate the compiler already knew. Rust has no subtyping over traits and no general test; `dyn Any::downcast_ref::<T>()` compares one concrete `TypeId` for equality, deliberately offering identity rather than membership. ## Why this matters in design Every type test is a place where your program branches on identity rather than on behaviour, and the three relations fail in different ways. A nominal test rejects a perfectly capable adapter that forgot to declare the interface. A structural test accepts a type that has the right method by coincidence and the wrong meaning. A constructor-identity test fails on values that crossed a boundary. That is why the durable advice is to test capability, or better, to dispatch rather than test at all -- but you cannot even state which failure you are exposed to until you know which relation your language's operator implements.