Reflection, Metadata, And Runtime Inspection

Solution

<?php

declare(strict_types=1);

class Container
{
    public function make(string $class): object
    {
        $reflection = new ReflectionClass($class);
        $constructor = $reflection->getConstructor();

        if ($constructor === null || $constructor->getNumberOfParameters() === 0) {
            return new $class();
        }

        $arguments = [];
        foreach ($constructor->getParameters() as $param) {
            $type = $param->getType();

            if (!$type instanceof ReflectionNamedType || $type->isBuiltin()) {
                throw new InvalidArgumentException(
                    "Cannot autowire parameter \${$param->getName()} of {$class}: no resolvable class type."
                );
            }

            $arguments[] = $this->make($type->getName());
        }

        return $reflection->newInstanceArgs($arguments);
    }
}

class Logger {}

class Mailer
{
    public function __construct(private Logger $logger) {}
}

class OrderService
{
    public function __construct(private Mailer $mailer, private Logger $logger) {}
}

$container = new Container();
$order = $container->make(OrderService::class);

echo get_class($order) . "\n";
// Prints:
// OrderService

Why This Works

ReflectionClass::getConstructor() returns null for a class with no declared constructor (like Logger) — the base case that stops the recursion. For every other class, each parameter's ReflectionNamedType is inspected: isBuiltin() is true for scalar types (string, int, array, ...) and false for class/interface types, which is exactly the distinction the container needs to decide "can I build this myself?" versus "I need a value I have no way to guess."

The recursive call to $this->make($type->getName()) is what lets OrderService — which depends on Mailer, which itself depends on Logger — get built in one top-level call. The container never needed to know that dependency chain existed; it discovered it by reading types, the same idea as the opening Product example in the article but chained through multiple levels.

newInstanceArgs() is Reflection's way of calling a constructor with a computed array of arguments — the Reflection equivalent of new $class(...$arguments).

Design Note

• Owner: whoever maintains the container/bootstrap code — application code that calls $container->make() should never need to know autowiring is happening.
• Trust boundary: $class should come from application configuration or a fixed set of known service classes, never directly from user input — the article's security note applies here: an attacker-controlled class name handed to make() can trigger construction of arbitrary classes.
• Positive path: make(OrderService::class) returns a fully wired OrderService.
• Rejected path: a class with an untyped or scalar-typed constructor parameter throws InvalidArgumentException naming the parameter, rather than silently passing null.
• Evidence: a test asserting make(OrderService::class) returns an instance whose injected Mailer/Logger are non-null, plus a test asserting the scalar-parameter case throws.

Diagnosis

Immediate cause. Money's constructor promotes private readonly int $cents — the property is actually named cents, not amountCents. new ReflectionProperty($money, 'amountCents') asks Reflection for a property that doesn't exist, and Reflection throws ReflectionException at runtime because there is nothing else it can do — there's no property to hand back.

Why nothing caught this earlier. 'amountCents' is a plain string, not a language-level reference to a property. PHPStan, IDE autocomplete, and PHP itself all check that $obj->cents refers to a real property because cents appears as an identifier the type checker can resolve against the class declaration. A string passed to ReflectionProperty's constructor is just data as far as the type system is concerned — nothing checks it against Money's actual properties until the line executes. This is exactly the "loss of static analysis" cost the article names: Reflection trades compile-time safety for runtime flexibility, and this bug is what that trade costs when it goes wrong.

The deeper design problem. Even with the correct property name ('cents'), this code is wrong. $cents is declared readonly — the language is stating explicitly that a Money object's cents value must never change after construction. setAccessible(true) and ReflectionProperty::setValue() can still write to a readonly property from outside the class in older PHP versions where this trick sometimes worked, but doing so defeats the entire point of declaring it readonly: any other code that received a Money and assumed it was immutable — cached it, used it as an array key, compared it before and after a call — is now wrong. Using Reflection to route around a readonly property is the article's warning about bypassing encapsulation made concrete: the fix isn't a correct property name, it's not using Reflection here at all.

Fix

Money should express "produce an updated value" the way immutable value objects do: return a new instance instead of mutating the existing one.

<?php

declare(strict_types=1);

class Money
{
    public function __construct(private readonly int $cents) {}

    public function cents(): int
    {
        return $this->cents;
    }

    public function withCents(int $newCents): self
    {
        return new self($newCents);
    }
}

$price = new Money(500);
$updated = $price->withCents(750);

echo $price->cents() . ' ' . $updated->cents();
// Prints:
// 500 750

No Reflection, no string-typed property name, and $price is provably unchanged — exactly the guarantee readonly was declared to make. This is the general shape of the fix whenever Reflection is being used to reach past a visibility or immutability modifier in application code: add the method the class should have had, rather than a bypass around the one it does.

1. Is Reflection actually necessary here? If the target class is known at write time — not passed in as a variable class name, not one of an open-ended set the framework must support generically — ask why ->, ::, or an interface method wouldn't do the job. Reflection justified by "it was the fastest way to get this working" is the article's warning sign: application code with a known class should use ordinary access operators.

2. Where does this run, and how often? A ReflectionClass scan inside a request-handling loop (re-reflecting the same class on every request) is a performance red flag; the same scan done once at container/framework bootstrap, or ahead of time in a compiled cache, is the pattern the article describes as normal. Check the call site's position, not just that reflection exists somewhere in the codebase.

3. Does it reach past a visibility or readonly modifier? If the code calls setAccessible(true) on a private property or method, or writes to a readonly property, that must be justified in the PR description (serialization library restoring state, a test asserting on internal state) — not left implicit. Absent a specific justification, this is the article's routing-around-encapsulation smell, and the reviewer should ask for a public method or constructor change instead.

4. What happens to static analysis coverage? Any property or method name passed to Reflection as a string (getProperty('cents'), getMethod('increment')) is invisible to PHPStan/IDE refactoring tools — renaming the real property will not update the string, and nothing will flag the mismatch until it fails at runtime, the way 02-diagnose-a-failure demonstrated. The reviewer should check whether the string is a literal near the class it targets (easier to keep in sync manually) or has drifted far from it (harder, and worth a comment explaining the coupling).

5. Where does the class/method/property name being reflected on come from? If it is a hardcoded literal, that's the safe case. If it is a variable — built from configuration, a route parameter, or (worst case) user input — treat it as untrusted input choosing which code runs, per the article's security note, and confirm there's an allow-list or equivalent restriction rather than an open new ReflectionClass($anyString).

6. Is there a test for the shape this code expects, including the missing-shape case? If the code reads an attribute off a method, is there a test for a method that lacks the attribute? If it reads a constructor parameter's type, is there a test for a parameter with no type or a scalar type (mirroring 01-design-the-first-version's InvalidArgumentException case)? Reflection code fails differently from ordinary code — usually with a generic ReflectionException or a silent null — so the reviewer should confirm the failure path was deliberately tested, not just the happy path.

7. Is the reason for using Reflection documented at the call site? A one-line comment or PR description explaining why this couldn't be a normal method call saves the next maintainer from re-litigating the decision, and gives a future reviewer a way to tell whether the original justification still holds.

A checklist that only confirms "the Reflection code runs and returns the expected value in the happy-path test" should not pass review — it proves the demo works, not that the design choice was sound or that failure modes were considered.