Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129716
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Mon, 29 Dec 2025 10:21:12 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <998d891b-d4f9-4fc1-9c71-d7607052506a@app.fastmail.com>
In-Reply-To: <C537E26A-9088-4507-8468-FCCE534A5906@gmail.com>
References: <C537E26A-9088-4507-8468-FCCE534A5906@gmail.com>
Subject: Re: [PHP-DEV] [Discussion] Reflection-based constructor autowiring (scope
 clarification)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Sun, Dec 28, 2025, at 3:39 AM, ANDR=C3=81S Zolt=C3=A1n Gy=C3=A1rf=C3=A1=
s wrote:
> Hello internals,
>
> My name is Zolt=C3=A1n Gy=C3=A1rf=C3=A1s Andr=C3=A1s (aka Zoli). I am =
a long-time PHP=20
> developer, primarily working on large PHP codebases where=20
> constructor-based dependency injection is used extensively.
>
> Before preparing a formal RFC, I would like to clarify the scope and=20
> intent of a small, opt-in idea and gather early feedback from the list.
>
> The idea is to introduce a *minimal reflection-based constructor=20
> autowiring primitive* into the core, exposed explicitly via the=20
> Reflection API, for example:
>
> `ReflectionClass::newInstanceAutowire(array $overrides =3D [], ?callab=
le=20
> $resolver =3D null): object
> `
> This proposal is intentionally narrow. To avoid misunderstandings, I=20
> would like to clearly explain what the idea *does* and *does not*=20
> include.
>
> *Key points of the idea, explained in detail:*
>
> *1. Explicit opt-in (no change to the `new` operator)*
> Autowiring would only happen when the developer explicitly calls the=20
> new Reflection API.
> The semantics of the `new` operator remain unchanged. Existing code=20
> paths are not affected, and there is no implicit dependency resolution=20
> anywhere in the language.
>
> *2. No global container or service registry*
> The proposal does not introduce a global container, service locator, o=
r=20
> registry of any kind.
> Each autowiring operation is local to the call site and bound to the=20
> current call stack. No global state is created or reused across calls.
>
> *3. No implicit interface-to-implementation mapping*
> When a constructor depends on an interface or abstract class, the core=20
> does not attempt to guess or discover a concrete implementation.
> Such mappings are inherently policy decisions and vary widely between=20
> frameworks. Instead, an explicit resolver callback is required if=20
> non-instantiable types are involved.
>
> *4. Scalar parameters require overrides or defaults*
> Scalar and builtin parameters are treated as configuration values. The=20
> core does not read environment variables, configuration files, or=20
> globals.
> As a result, scalar parameters must either have default values or be=20
> provided explicitly via the `$overrides` argument.
>
> *5. Interface and abstract types require an explicit resolver callback*
> Interfaces and abstract classes are never instantiated automatically.
> If encountered during autowiring, the core either delegates resolution=20
> to the provided resolver callback or fails with a clear exception. Thi=
s=20
> keeps architectural decisions firmly in userland.
>
> *6. Deterministic circular dependency detection*
> Autowiring necessarily builds an object graph. The proposal includes=20
> mandatory detection of circular dependencies within that graph.
> When a cycle is detected, a deterministic and descriptive exception is=20
> thrown, rather than allowing infinite recursion or a stack overflow.
>
> *7. Request-scope caching of constructor metadata only*
> For performance reasons, constructor metadata (parameter lists, types,=20
> defaults) may be cached for the duration of the request.
> No object instances are cached, no lifetimes are managed, and no=20
> persistent or global caches are introduced.
>
> At this stage, I am primarily interested in feedback on whether this=20
> level of restraint is sufficient to keep the feature aligned with PHP=E2=
=80=99s=20
> =E2=80=9Cmechanism, not policy=E2=80=9D philosophy, and whether there =
are any immediate=20
> concerns regarding reflection, error handling, or performance.
>
> If the direction seems reasonable, I plan to follow up with a draft RF=
C=20
> on wiki.php.net that incorporates the feedback from this discussion.
>
> Thank you for your time and insights.
>
> Best regards,
>
> Zoli

I am unclear what advantage this offers over the status quo, or who the =
intended user is.  Is the intent to be "an alternative to existing DI co=
ntainers" (in which case, what does it offer that would make me use it i=
nstead of Symfony DI, PHP-DI, rolling my own, etc.), or is it "a tool th=
at existing DI containers can use to be better" (in which case, how is i=
t better than the existing options for them)?  Those are two different g=
oals that would have two different designs.

For example, lazy object proxies already existed in user-space.  However=
, the amount of fugly code it required was high, so moving that logic in=
to the engine where it could take advantage of engine-only features to p=
rovide a far cleaner API and better performance was a win, and allows th=
e removal of lots of fugly code from existing projects (when they upgrad=
e).  I'm not clear where such a win can be found with this proposal.

--Larry Garfield