Several languages ship built-in help for making one object stand in for another: Kotlin's `by` clause, Scala 3's `export`, Go struct embedding, Ruby's Forwardable/SimpleDelegator, and Python's `__getattr__`. Compare what each of them actually generates, and what each one cannot do.

## The problem these features solve When one object stands in for another — a wrapper that adds logging, a decorator that adds caching, an adapter that renames — you have to re-expose the inner object's methods. Written by hand that is one stub per member: `fun m(a) = inner.m(a)`. For a twenty-member interface that is twenty bodies with no logic in them, which must be revisited every time the interface grows. Several languages ship a feature that writes those stubs for you. The single most important fact about all of them: they generate **forwarding**. Each produces (or simulates at run time) a call `inner.m(...)`. None of them tells the inner object that it is being wrapped, and none re-binds the inner object's notion of self. ## Kotlin: the `by` clause `class Logged(private val d: Repo) : Repo by d` makes the compiler emit an implementation of every member of `Repo` that calls `d.m(...)`. Constraints worth naming: the delegated type must be an **interface**; the delegate expression is evaluated once at construction and stored in a hidden field, so there is no run-time swap; and any member you override in `Logged` is invisible to `d` — code inside `d` calling `m()` runs `d`'s own `m`. ## Scala 3: `export` `export inner.*` generates forwarders as ordinary members of the enclosing class or object, and you can select (`export inner.{read, write}`), rename, or exclude members. Nothing about `export` makes your class a subtype of the exported type. That is the sharpest contrast with Kotlin: in Kotlin, `by` is simultaneously the subtyping declaration and the forwarding declaration, so you get the whole interface or nothing; in Scala 3 you decide those two things separately. ## Go: struct embedding `type Wrap struct { Inner }` promotes `Inner`'s methods and fields onto `Wrap` by name at compile time. Promotion is shallowest-wins: a method declared directly on `Wrap` shadows the promoted one, and two embedded types offering the same name at the same depth are not an error until a call site selects it. Promotion also carries interface satisfaction — `Wrap` satisfies whatever `Inner` satisfies, which is why embedding is Go's mixin idiom. The receiver of a promoted method is still the `Inner` value, and Go supplies no interception hook at all. ## Ruby: Forwardable and SimpleDelegator `extend Forwardable; def_delegators :@inner, :read, :write` metaprograms named methods when the class body runs — an explicit whitelist, compiled once. `SimpleDelegator` is the catch-all sibling: it forwards unknown messages through `method_missing`, and it lets you replace the target at run time with `__setobj__`. That retargeting is something none of the compile-time features can do. ## Python: `__getattr__` `def __getattr__(self, name): return getattr(self._inner, name)` is the most permissive mechanism on the list. It forwards everything the wrapper does not define, including names that are typos, and it works on objects whose surface is not known statically. It also has a trap that catches people repeatedly: **implicit special-method invocation looks the dunder up on the type, not the instance**, so `len(w)`, `w[i]`, `with w`, `w + y` and iteration never reach `__getattr__`. `w.__len__()` works; `len(w)` raises `TypeError`. Wrapping anything protocol-shaped in Python means writing the dunders out explicitly. ## The three axes to remember 1. **Whitelist vs whole surface.** Scala's `export` and Ruby's `def_delegators` name members. Kotlin's `by` and Go embedding take a declared type's entire surface. `__getattr__` and `method_missing` take everything, known or not. 2. **When the target is bound.** Compile time for Kotlin, Scala and Go; class-definition time for `def_delegators`; per call for `__getattr__` and `SimpleDelegator` — and only that last group can swap the target on a live object. 3. **Whether there is a seam.** Dynamic mechanisms give you exactly one place to add a cross-cutting concern (timing, retries, auditing) for every member. The static generators give you none: to instrument one member you must write it by hand and let the generator cover the rest. ## What none of them buy you No mechanism here makes the inner object cooperate with the outer one. The inner object's self-calls, the identity it hands to callbacks, and the type it reports all remain the inner object's. That is the same for Kotlin, Scala, Go, Ruby's Forwardable and Python's `__getattr__` — which is why the language-level support removes typing, not the design consequences of wrapping.