Some runtimes let a running program manufacture a brand-new class: Python's built-in `type(name, bases, namespace)`, Ruby's `Class.new`, and the Objective-C runtime's `objc_allocateClassPair` + `objc_registerClassPair` pair. Several also fire a hook the instant a subtype appears — Python's `__init_subclass__`, Ruby's `inherited`. Other platforms fix the set of types before the program starts: Rust has no runtime class construction, Go's `reflect.StructOf` can fabricate a struct shape but cannot attach methods to it, and a GraalVM native-image binary only contains types the build could see. What does runtime type construction buy a framework author, what does closing the type set buy in return, and how do you decide which cost your system pays?

## The question behind the question Every platform answers: **at what moment is the set of types in this program final?** Rust and Go answer *at build*. C# and Java answer *mostly at load*, with escape hatches. Python, Ruby, Smalltalk and the Objective-C runtime answer *never* — a new class can appear at any instant. Runtime type construction is the ability to create a type that no source file declared, complete with a name, a superclass, fields and methods, while the process is running. ## What construction buys **Types derived from data.** An object-relational mapper reads a schema and produces one class per table with one attribute per column. In Python this is a metaclass — a class whose instances are classes — running at import: Django's `ModelBase`, SQLAlchemy's declarative machinery, Pydantic's model metaclass all inspect the declared body and build the finished type from it. In Ruby, `Class.new(Base)` returns an anonymous class you can name by assigning it to a constant; `Struct.new` is the same trick in the standard library. On a closed platform the equivalent is a *build-time code generator* or *load-time bytecode synthesis*: an extra pipeline stage, an extra artifact, and a new way for generated code to drift from its source. **Registration without a scanner.** `__init_subclass__` and Ruby's `inherited` fire at the moment a subtype is defined. A plugin base class can therefore collect its own implementations as modules load — no configuration file, no classpath scan, no annotation processor. Closed-world equivalents all reintroduce the ceremony the hook removed: a service-provider descriptor, a startup scan of the deployed units, or a build-time registry. **Behavioral interception.** Apple's key-value observing does not patch your class; it *creates a subclass* (`NSKVONotifying_Foo`) with overridden setters and repoints the observed instance at it. Runtime class construction is the mechanism, and it is invisible to the code being observed. ## What closing the set buys **Layout and dispatch.** If no new type can appear, every field offset and every vtable is known at link time, generics can be monomorphized, and a call with one known implementor can be devirtualized outright. **Dead-code elimination.** Whole-program compilers and linkers delete what nothing reaches. This is exactly what an open world breaks: a method that only a runtime-built type will ever call looks unreachable, gets stripped, and the failure surfaces in production rather than in the build. **Comprehension and audit.** A member that exists only because a metaclass created it is invisible to grep, to IDE completion, and to a reviewer. Every open ecosystem eventually bolts on a *second, static* description to recover this — Python stub files, Ruby signature files, gradual type checkers — which is a static type system smuggled back in beside the dynamic one. **Go's deliberate half-step is instructive.** `reflect.StructOf` will fabricate a struct type at runtime, so serializers can build a shape from data. It will not give that type methods. Data shapes stay open; *behavior* stays closed, and the compiler keeps its assumptions. ## The distinction most candidates miss Constructing a type and generating machine code are different capabilities, and platforms restrict them separately. Objective-C class construction works fine on iOS, where runtime code generation is forbidden, because the methods you install are pointers to functions the AOT compiler already emitted — you are assembling metadata, not writing instructions. .NET's `Reflection.Emit` is unavailable under iOS and NativeAOT for the opposite reason: it emits new IL that would need a JIT. Interpreted platforms blur this only because their "code" is data the interpreter walks. GraalVM native-image is the clearest modern case of the tradeoff being priced. The JVM permits load-time class definition, and frameworks lean on it heavily — proxies, mocks, lambda call sites. Native-image performs closed-world analysis, so anything reached only reflectively or defined at runtime must be declared in build-time reachability metadata; otherwise the code was never compiled into the binary. Frameworks responded by moving work from runtime to build time, which is not a workaround but a genuine architectural shift. ## How to decide Ask what your deployment target is, not what your language allows. If you ship a native binary, a mobile app, a serverless function judged on cold start, or anything with a whole-program optimizer, openness is paid for in configuration files, fragile metadata, and failures that only appear in the packaged build. If you ship a long-lived JIT-compiled service where startup is amortized and a profiler can speculate on the shapes that actually occur, the same openness is nearly free and buys real leverage for framework authors. And note the convergence: open platforms retrofit static descriptions to get tooling back; closed platforms retrofit code generation to get dynamism back. Choosing a platform is largely choosing which retrofit your team maintains.