In most class-based languages a call like obj.method() is resolved from the object's actual class, while a read like obj.field is resolved from the declared type of the expression obj. Why does state bind to the declared type, and how do the languages that do let a subtype substitute state actually achieve it?

## The one-line mechanism When a language compiles an object to a fixed memory layout, an instance is a block of memory and each declared field sits at a known offset inside it. The compiler computes that offset from the **declared** (static) type of the expression you wrote, and emits a load. On the JVM the `getfield` instruction names the owning class directly in the class file's constant pool; in C++ it is literally a base pointer plus a constant. A virtual call is different in kind. The object carries a pointer to a per-class dispatch table (vtable, method table, itable). The call site reads a fixed *slot* of that table, and the *contents* of the slot differ per class. That single indirection is the whole of subtype polymorphism. State has no such indirection, so there is nothing to substitute. So "fields are not polymorphic" is not a rule someone sat down and chose; it falls out of representing state as layout. The useful corollary is: **anything a subtype should be able to substitute must be reachable through an indirection, which in practice means it must be method-shaped.** ## Field hiding, and why it burns people Because the binding uses the declared type, a subclass that declares a field with a name the base already uses does not replace it — it **hides** it. Both fields exist in the object simultaneously, and which one you read depends only on how the reading expression is typed. In Java and C# `((Base) d).x` and `d.x` read two different storage slots of one object; `super.x`/`base.x` reaches the hidden one. C++ behaves the same way and adds *slicing*: assigning a derived object by value into a base-typed variable copies only the base sub-object, so the derived state is not merely unreachable, it is gone. Methods have the opposite property: one object, one behaviour, regardless of the reader's type. ## Making state substitutable: three timing regimes Bertrand Meyer's *uniform access principle* says a client should not be able to tell whether a value is stored or computed. Languages honour it at three different points in time, and that choice decides whether "expose a field" is a safe decision. **Opt in at compile time (C#, and Java by convention).** Fields are never virtual and cannot be intercepted; only a property declared `virtual` can be overridden. Converting a published public field into a property is source-compatible but **binary**-incompatible — assemblies already compiled against the field emit a field-access instruction and break — and a field can be passed by `ref`/`out` where a property cannot. The escape hatch must therefore be reserved up front, which is exactly why .NET guidance forbids public fields in libraries and why the Java ecosystem grew getters everywhere. **Accessors by default (Kotlin, Swift).** In Kotlin, `val`/`var` are accessors from the caller's side and the backing field is an implementation detail, so marking a `val` as `open` makes overriding it genuine dispatch (a subclass may even widen an `open val` to a `var`). Swift goes further: a subclass may override an inherited **stored** property with a computed one, or attach `willSet`/`didSet` observers to an inherited property. Both languages let you start with something that looks like a field and later make it computed without touching a single caller. **Always, at run time (Python, Ruby, Objective-C).** Python has no offsets worth speaking of: `obj.x` consults descriptors found on the type along the MRO and the instance dictionary, so a class attribute can intercept the read entirely and `__getattr__` can synthesise attributes that were never declared. Ruby is stricter still — instance variables are unreachable from outside, every read goes through a method, so a subclass overrides a reader like any other method. Objective-C `@property` synthesises accessor methods reached by message send, interceptable even at run time. ## The Python caveat worth knowing Uniform access in Python is real but not free. A `property` is a **data descriptor**: it always defines `__set__`, which raises when no setter was supplied, and data descriptors defined on the type take precedence over the instance dictionary. So if a base `__init__` does `self.balance = 0` and a subclass declares `balance` as a getter-only `@property`, merely *constructing* the subclass raises an `AttributeError` about the missing setter — before any caller reads anything. The conversion is caller-transparent, not constructor-transparent. Give the override a setter, or do the stored-to-computed conversion inside the class that owns the assignment. ## What the asymmetry costs in real systems 1. **Interception tools only see dispatch.** Dynamic proxies, mocking libraries, lazy-loading ORM wrappers and instrumentation layers work by subclassing and intercepting calls. A public field is invisible to all of them — an ORM cannot lazily populate it through a proxy, a mock cannot fake it. (ORMs that map fields do it by reflection or bytecode weaving, not by dispatch.) In Python all three work on plain attributes, because attribute access itself is interceptable. 2. **API evolution is reversible in some languages and not others.** Advice copied between ecosystems without this context is how mandatory getters arrived in languages that never needed them. 3. **Buying dispatch buys its hazards** — an overridable accessor invoked during base-class construction runs the subclass version before the subclass's storage exists — but that is a consequence of the indirection, not of the binding rule itself. ## The rule to remember Expose state as an accessor — or work in a language where every access already is one — if a subtype, a proxy, an ORM or a test double should ever be able to substitute it. Never rely on a shadowed field name for meaning: it is one object with two slots and the reader's declared type picks. Where the language lets you change your mind later (Kotlin, Swift, Python, Ruby), a plain property declaration is the honest one and a hand-written getter that only returns the field is ceremony.