Why does a lazily loaded stand-in break a type test, a cast, or an equality comparison against the mapped class?

## What the caller is actually holding A deferred link is not the mapped object with empty fields. It is a **separate object of a type the layer generated**, built to be assignable where the declared type is expected: it extends the mapped class, or implements the interface the field was declared as. Inside, it holds the key and a reference back to the layer; each intercepted call checks whether the target has been fetched, fetches it if not, and forwards the call. That design has one purpose — to make deferral invisible — and it succeeds for the operations the interception covers. Everything it does not cover leaks the difference between the stand-in and the real instance, and those leaks are the classic interview material. ## The three leaks | Operation | What happens | Why | |---|---|---| | Test against the **declared base type** | Passes | The generated type is a subtype of it | | Test against the **exact runtime class** | Fails | The runtime class is the generated one | | Cast to a **concrete subtype** of a mapped hierarchy | Fails | The stand-in was generated over the *declared* type | | Equality **from the real instance** | Often false | It compares runtime classes and sees a subtype | | Equality **from the stand-in** | Often true | The call is forwarded and runs on the target | | **Direct field read** on the stand-in | Empty value | The state lives on the target, not the placeholder | **1. Type identity.** Code that asks "is this object exactly this class" gets a no. This bites in dispatch tables keyed by class, in test assertions, and in anything that logs or routes on class identity. A base-type test still passes, which is why the problem shows up only in the places that insisted on exactness. **2. Downcasting in a mapped hierarchy.** When a mapped class has subtypes and a link is declared as the base type, the layer must generate the stand-in over the base type — at the time it is created, nobody has read the row, so nobody knows which subtype the row is. The subtype becomes known when the load fires, but the object handed to the caller cannot change its own runtime class. So the downcast fails **even after the link is loaded**, which is the counter-intuitive part. Escapes are to unwrap the stand-in through the layer's own helper and cast the result, to model the branch as behaviour on the base type instead of a cast, or to arrange for the link to be fetched by the query so no stand-in is ever created for it. **3. Equality and hashing.** Equality written by comparing the two objects' runtime classes answers differently depending on which object is on the left, because only one direction goes through the forwarding. That asymmetry violates the contract every hash-based container relies on, so a lookup can find an object one moment and miss it the next depending on which instance ended up in the container. Equality written over a **stable business key**, read through accessors, is symmetric and survives the stand-in. Equality written over a generated identifier has a second problem — the value is absent before the row is written — but at least it does not depend on the runtime class. ## Why direct field reads misbehave Interception usually covers calls, not raw field access. Three routes bypass it: - a read from **inside the class**, where the field is in scope directly; - a read from **another instance of the same class**, which has the same access; - **reflective tooling** that enumerates fields rather than calling accessors. Each of these reaches the *stand-in's* own field, which was never populated, rather than the target's. The value looks absent, which reads as data loss rather than as a missing load. Layers that instrument the class itself can intercept field reads too, so this is one of the places where honest advice is layer-dependent: keep mapped state behind accessors, or know that your layer rewrites field access and accept direct reads. ## What to do about it 1. **Compare by identifier, not by object.** Most of the comparisons that go wrong were really asking "is this the same row". 2. **Prefer base-type tests and behaviour over exact-class tests and casts** in code that can see mapped objects. 3. **Define equality once, over a business key, through accessors** — and if no business key exists, accept that identity comparison within one unit of work is the only reliable equality you have. 4. **Unwrap before you cast**, using whatever the layer offers for it, and treat the need to unwrap as a signal that the query should probably have fetched the link. 5. **Keep mapped objects out of generic frameworks that reason about classes** — serialisers, dispatchers, copiers — or give them the unwrapped instance.