Can a reusable unit of behaviour own instance state of its own? Compare how several named languages answer, and say what goes wrong in each.

## Why state is the dividing line A reusable unit that only provides behaviour composes cleanly: worst case two units provide the same name and the composer picks. A unit that owns *storage* is different, because storage raises questions that composition alone cannot answer. If two units both want a field, is that one slot or two? If a unit is attached twice through different paths, does its state exist twice? When is the field initialized relative to the composing class's own constructor? Every language that permits stateful units has had to answer these, and every answer has a documented failure mode. ## Scala: declared fields, ordered initialization A Scala trait may declare `val`, `var` and even a concrete constructor body. The compiler resolves the copy question by fiat: the field is emitted into each concrete class that mixes the trait in, so one instance holds one copy no matter how the trait was reached. What it cannot resolve is ordering. Initializers run in linearization order, so if a trait's own body reads a `val` that a later participant in the linearization defines, it reads the field's default - null for references, zero for numbers - and does so without any type error. The result is a NullPointerException far from the cause, or worse, a silently wrong zero. Scala's answers are `lazy val` (defer evaluation to first read), `def` instead of `val` where recomputation is acceptable, and in Scala 2 the early-definitions syntax that evaluated selected vals before the superclass chain. The existence of three workarounds is itself the evidence that stateful units cost something. ## Ruby: undeclared, colliding, silent Ruby modules have no field declarations. A module simply writes `@count` on `self`, and `self` is whatever object included the module. Nothing about this is checked: two modules that both use `@count` end up sharing one slot on every object that includes both, and no diagnostic is produced at definition, at inclusion, or at the first conflicting write - the symptom is a counter that advances twice as fast, or a cache that is invalidated by an unrelated feature. The only defence is naming convention, which is why mature Ruby libraries prefix module instance variables with the module name. Python's mixins share the hazard for the same reason: one attribute dictionary per instance and no declaration of ownership. ## Rust: state as a required capability Rust traits carry no per-instance data at all - only associated types, associated consts and methods. A trait that needs storage declares a required accessor, for example `fn buffer(&mut self) -> &mut Vec<u8>`, and writes its provided methods against that accessor. The implementor decides where the bytes live and whether two traits share one field or get separate ones, and that decision is written down in ordinary code a reviewer can read. Because nothing is injected implicitly, two traits can never collide over a slot neither declared. Rust also gets a property no mixin system has: coherence rules prevent two crates from providing the same trait implementation for the same type, so the cross-library collision case does not exist. ## Java, C#, Swift: bodies without fields Java 8 default methods and C# 8 default interface members were introduced to let published interfaces gain methods without breaking implementors - API evolution, not composition. Neither allows instance fields, so the state diamond simply cannot arise; a library that needs per-implementor state declares an abstract accessor, or ships a small helper object the implementor stores and delegates to. Swift lands in the same place from a different direction: a protocol extension can add a *computed* property (a getter, possibly a setter) but never a stored one; conformers declare the storage themselves, and code that needs to attach storage to types it does not own reaches for the Objective-C runtime's associated-object side table, which is a workaround with real costs around lifetime and thread safety. ## What to say in the interview State the three-way split with named languages, then make the theoretical point: allowing a unit to own storage reimports exactly the part of multiple inheritance that has no default answer. Flattening in particular has no story for state - if composition means "as if written directly in the class", then two units contributing the same field name are contributing the same field, which is almost never what either author meant. That is why the original trait model was defined as stateless, and why the later "stateful traits" research had to add explicit operations for merging and freezing state rather than letting it fall out of composition. A good closing observation is that the accessor-requirement pattern is available in every language, including the ones that permit stateful units: you can write Scala traits with `def buffer: Buffer` instead of `val buffer`, and get the same auditability at the cost of one line per implementor.