Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129709
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_3366265F-35AE-48F4-9DE9-CD85A809DB71"
Precedence: list
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\))
Subject: [PHP-DEV] [Discussion] Reflection-based constructor autowiring (scope clarification)
Message-ID: <C537E26A-9088-4507-8468-FCCE534A5906@gmail.com>
Date: Sun, 28 Dec 2025 11:39:44 +0200
To: "internals@lists.php.net" <internals@lists.php.net>
From: azolee@gmail.com (=?utf-8?B?QU5EUsOBUyBab2x0w6FuIEd5w6FyZsOhcw==?=)


--Apple-Mail=_3366265F-35AE-48F4-9DE9-CD85A809DB71
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hello internals,

My name is Zolt=C3=A1n Gy=C3=A1rf=C3=A1s Andr=C3=A1s (aka Zoli). I am a =
long-time PHP developer, primarily working on large PHP codebases where =
constructor-based dependency injection is used extensively.

Before preparing a formal RFC, I would like to clarify the scope and =
intent of a small, opt-in idea and gather early feedback from the list.

The idea is to introduce a minimal reflection-based constructor =
autowiring primitive into the core, exposed explicitly via the =
Reflection API, for example:

ReflectionClass::newInstanceAutowire(array $overrides =3D [], ?callable =
$resolver =3D null): object
This proposal is intentionally narrow. To avoid misunderstandings, I =
would like to clearly explain what the idea does and does not 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 new =
Reflection API.
The semantics of the new operator remain unchanged. Existing code paths =
are not affected, and there is no implicit dependency resolution =
anywhere in the language.

2. No global container or service registry
The proposal does not introduce a global container, service locator, or =
registry of any kind.
Each autowiring operation is local to the call site and bound to the =
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 =
does not attempt to guess or discover a concrete implementation.
Such mappings are inherently policy decisions and vary widely between =
frameworks. Instead, an explicit resolver callback is required if =
non-instantiable types are involved.

4. Scalar parameters require overrides or defaults
Scalar and builtin parameters are treated as configuration values. The =
core does not read environment variables, configuration files, or =
globals.
As a result, scalar parameters must either have default values or be =
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 =
to the provided resolver callback or fails with a clear exception. This =
keeps architectural decisions firmly in userland.

6. Deterministic circular dependency detection
Autowiring necessarily builds an object graph. The proposal includes =
mandatory detection of circular dependencies within that graph.
When a cycle is detected, a deterministic and descriptive exception is =
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, =
defaults) may be cached for the duration of the request.
No object instances are cached, no lifetimes are managed, and no =
persistent or global caches are introduced.

At this stage, I am primarily interested in feedback on whether this =
level of restraint is sufficient to keep the feature aligned with =
PHP=E2=80=99s =E2=80=9Cmechanism, not policy=E2=80=9D philosophy, and =
whether there are any immediate concerns regarding reflection, error =
handling, or performance.

If the direction seems reasonable, I plan to follow up with a draft RFC =
on wiki.php.net that incorporates the feedback from this discussion.

Thank you for your time and insights.

Best regards,

Zoli



eng. ANDR=C3=81S Zolt=C3=A1n-Gy=C3=A1rf=C3=A1s
---------------------------------------
tel: +40 745 797 798
mail: azolee@gmail.com


--Apple-Mail=_3366265F-35AE-48F4-9DE9-CD85A809DB71
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;"><p>Hello =
internals,</p><p>My name is Zolt=C3=A1n Gy=C3=A1rf=C3=A1s Andr=C3=A1s =
(aka Zoli). I am a long-time PHP developer, primarily working on large =
PHP codebases where constructor-based dependency injection is used =
extensively.</p><p>Before preparing a formal RFC, I would like to =
clarify the scope and intent of a small, opt-in idea and gather early =
feedback from the list.</p><p>The idea is to introduce =
a&nbsp;<strong>minimal reflection-based constructor autowiring =
primitive</strong>&nbsp;into the core, exposed explicitly via the =
Reflection API, for =
example:</p><pre><code>ReflectionClass::newInstanceAutowire(array =
$overrides =3D [], ?callable $resolver =3D null): object
</code></pre><p>This proposal is intentionally narrow. To avoid =
misunderstandings, I would like to clearly explain what the =
idea&nbsp;<em>does</em>&nbsp;and&nbsp;<em>does =
not</em>&nbsp;include.</p><p><strong>Key points of the idea, explained =
in detail:</strong></p><p><strong>1. Explicit opt-in (no change to =
the&nbsp;<code>new</code>&nbsp;operator)</strong><br>Autowiring would =
only happen when the developer explicitly calls the new Reflection =
API.<br>The semantics of the&nbsp;<code>new</code>&nbsp;operator remain =
unchanged. Existing code paths are not affected, and there is no =
implicit dependency resolution anywhere in the =
language.</p><p><strong>2. No global container or service =
registry</strong><br>The proposal does not introduce a global container, =
service locator, or registry of any kind.<br>Each autowiring operation =
is local to the call site and bound to the current call stack. No global =
state is created or reused across calls.</p><p><strong>3. No implicit =
interface-to-implementation mapping</strong><br>When a constructor =
depends on an interface or abstract class, the core does not attempt to =
guess or discover a concrete implementation.<br>Such mappings are =
inherently policy decisions and vary widely between frameworks. Instead, =
an explicit resolver callback is required if non-instantiable types are =
involved.</p><p><strong>4. Scalar parameters require overrides or =
defaults</strong><br>Scalar and builtin parameters are treated as =
configuration values. The core does not read environment variables, =
configuration files, or globals.<br>As a result, scalar parameters must =
either have default values or be provided explicitly via =
the&nbsp;<code>$overrides</code>&nbsp;argument.</p><p><strong>5. =
Interface and abstract types require an explicit resolver =
callback</strong><br>Interfaces and abstract classes are never =
instantiated automatically.<br>If encountered during autowiring, the =
core either delegates resolution to the provided resolver callback or =
fails with a clear exception. This keeps architectural decisions firmly =
in userland.</p><p><strong>6. Deterministic circular dependency =
detection</strong><br>Autowiring necessarily builds an object graph. The =
proposal includes mandatory detection of circular dependencies within =
that graph.<br>When a cycle is detected, a deterministic and descriptive =
exception is thrown, rather than allowing infinite recursion or a stack =
overflow.</p><p><strong>7. Request-scope caching of constructor metadata =
only</strong><br>For performance reasons, constructor metadata =
(parameter lists, types, defaults) may be cached for the duration of the =
request.<br>No object instances are cached, no lifetimes are managed, =
and no persistent or global caches are introduced.</p><p>At this stage, =
I am primarily interested in feedback on whether this level of restraint =
is sufficient to keep the feature aligned with PHP=E2=80=99s =
=E2=80=9Cmechanism, not policy=E2=80=9D philosophy, and whether there =
are any immediate concerns regarding reflection, error handling, or =
performance.</p><p>If the direction seems reasonable, I plan to follow =
up with a draft RFC on wiki.php.net that incorporates the feedback from =
this discussion.</p><p>Thank you for your time and insights.</p><p>Best =
regards,</p><p>Zoli</p><p><br></p><div>
<div style=3D"color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; orphans: auto; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; widows: =
auto; word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px;">eng. ANDR=C3=81S =
Zolt=C3=A1n-Gy=C3=A1rf=C3=A1s<br>---------------------------------------<b=
r>tel: +40 745 797 798<br>mail:&nbsp;azolee@gmail.com</div>
</div>
<br></body></html>=

--Apple-Mail=_3366265F-35AE-48F4-9DE9-CD85A809DB71--