Lazy Objects (PHP 8.4)
debt(d7/e3/b3/t5)
Closest to 'only careful code review or runtime testing' (d7). The term's detection_hints.automated is 'no', and while the code pattern `newLazyGhost|newLazyProxy` can be searched for, misuse (using lazy objects for always-used services, or accessing uninitialized objects incorrectly) won't be caught by standard linters or SAST tools. Issues surface at runtime when performance isn't improved or when unexpected behaviour occurs.
Closest to 'simple parameterised fix' (e3). The quick_fix indicates using ReflectionClass::newLazyGhost() for deferred service initialisation. Fixing misuse typically involves changing DI container configuration or switching between ghost/proxy patterns — localized changes within service registration code, not cross-cutting refactors.
Closest to 'localised tax' (b3). Applies to web, cli, queue-worker contexts but lazy objects are typically isolated to DI container bootstrap logic. The choice affects service instantiation patterns but doesn't impose load-bearing constraints across the entire codebase — it's contained within infrastructure code.
Closest to 'notable trap' (t5). The misconception explicitly states developers wrongly believe lazy objects are 'only useful for ORMs' when they're broadly useful for any expensive service. Additionally, common_mistakes highlight confusion between ghost (modifies in place) vs proxy (returns new instance) semantics, and unexpected behaviour when accessing uninitialized objects — documented gotchas most PHP 8.4 developers will eventually learn.
TL;DR
Explanation
Two strategies: ghost objects (ReflectionClass::newLazyGhost) — same class, initialiser called on first access; virtual proxies (ReflectionClass::newLazyProxy) — returns a different instance on first access. Initialiser receives the uninitialised object. Skipping initialisation: markLazyObjectAsInitialized(). Reset: resetAsLazyGhost(). Use cases: expensive service construction (DB connections, HTTP clients) in DI containers, lazy loading related entities in ORMs. PHP 8.4 lazy objects replace Doctrine/Symfony proxy generator libraries for simple cases. Properties can be marked lazy individually with ReflectionProperty::setRawValueWithoutLazyInitialization().
Common Misconception
Why It Matters
Common Mistakes
- Using lazy objects for services that are always used — adds overhead without benefit.
- Not understanding ghost vs proxy — ghost modifies in place, proxy returns new instance.
- Accessing uninitialized lazy object in a context that doesn't trigger initialisation.
Code Examples
// Before PHP 8.4 — manual proxy:
class LazyDbConnection {
private ?PDO $pdo = null;
public function query(string $sql): array {
$this->pdo ??= new PDO(DB_DSN);
return $this->pdo->query($sql)->fetchAll();
}
}// PHP 8.4 native lazy ghost:
$reflector = new ReflectionClass(DbConnection::class);
$lazy = $reflector->newLazyGhost(function(DbConnection $obj) {
// Called only on first property access:
$obj->__construct(getenv('DATABASE_URL'));
});
// Injected into container — no connection until actually used
$container->bind(DbConnection::class, fn() => $lazy);