Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:129714 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id 703F91A00BC for ; Mon, 29 Dec 2025 11:02:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1767006149; bh=Dm+fjRIUqHn0BXAhK+io4ZYOFP0vpSe7i+DhlEeUQtA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Nxo2d3bKHDdQWQVJESjJNV1OV2g+Rno3C1dAajuSgoYDxKUzFE2FJ/yMI4SQK9Qa+ O6bMqu8U3Vzn1co7Z9Ni7qOUmUy+GxHt1lphuGZ7HSOOZzSpBNosdPVnvFUUsWZyma j4gCZNYlTWhWZUR976uIo3jeoVQXiYnk7QODpVqvbmDlWsdxSAy2Pbvjjl/9UwlXZd unODBPkVTM73NszlBr1Nfp+V6OLmU4s2E3/nGjX1FwTxkzDc5k18amzrUG+qGPfjwt 6EZE5mfhD96LgjU+AX/RezO3m7LNeZr3y/K3lfl77uI5AnPL11UY7RNZRr6+0Z+3AA mDzUhg0MZzipg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 4DEF7180788 for ; Mon, 29 Dec 2025 11:02:24 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 29 Dec 2025 11:02:21 +0000 (UTC) Received: by mail-pf1-f178.google.com with SMTP id d2e1a72fcca58-7b22ffa2a88so8398097b3a.1 for ; Mon, 29 Dec 2025 03:02:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767006136; x=1767610936; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Dm+fjRIUqHn0BXAhK+io4ZYOFP0vpSe7i+DhlEeUQtA=; b=iljz0071OaysRNM/kNgXkSZwTxpKhzuJ5Y0W1vP4RvnCAQAR3+FJga1TjlCt6LrTif 44WGeEmZMALTsWjXAkcz/eXmcIov4GOj/ei/o/x/+/dHJ6exJUwxUiCsjam2286B617u e7uZ2rNDdWmWsWP18jHxVWzvYQfyD+UD512WTIvwefioPiyfSDrQvtQYnK2jTb8JhjGq Os6LvLNrR6MZzqiYkwMY+nbL3Z5keFahZezOPKayUcHOiDOGtc18Mg/8owmO2uf4v7M+ 6YuYHS/sZO+NxGswwlz6A5Rjy9Xr0cgOy0bawAfkDkah0VuIVWanACxarlR9dGj/YmwM oUFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767006136; x=1767610936; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Dm+fjRIUqHn0BXAhK+io4ZYOFP0vpSe7i+DhlEeUQtA=; b=gvbP1jSkQkKQWPpyote6JFO4PafQkIbKAFkVThqyYHqRG7uitSWRdAec3eNz9RdqL3 u5XuXvIa5Pdp9xU/rB3mavlqwaLT8hp3pCBACwIRF0z+MgvJCaGdTQVGDUa6lHv0ynOn zbbQAifntGpOscy8aBbdULcar6wDZtwWVDhf+ClETtP3etgdMqWUm9f2jEiwehOTeZ1m T8pcyeYZB3XRqC/oGWW/c9HPwHV4h5uUjqSx2Jm7guYagPPNeYn5AikMn1z3hIrBxa1T kzBsQoOnIA7g3XZ/oF0/DrotSn4lhWERRBn8E0ZvrDw6SADrtsX017+DbLXvStZQAqZU hr3Q== X-Gm-Message-State: AOJu0YyL0gBfF0CEo8UaBIYfwrJGyxB5TnYFOfcEzlLKI+ODiyrk6yjg g5zEQAhNzL1CzvZ064V7CJpJ1Yp5QO5vubPCOLFFJqL4otSA+R64DLQqzWcgGaTgOQHYB1l0Qj6 HJ6W5FosAnKTasZ5d9QuR/kBCsIS47jY= X-Gm-Gg: AY/fxX4YbJDBqMA1/H8HAG2ZSAs3h0pZeNEXiwfsVtIqaqqnCLYysRgLT96hIH5IHj0 Rsy6D/FWpFeiJoOfte7KyHn4uQi3VLEPwEF8iE+9FtdW+DB786v2ITei1aLKR+S0QZG2hp4al6Q UVi6QXDHSwcRPMVkswPJPRIoDeJP3qePxhGoC/QXgJE3wK/Dao6SNfDZBh1NW/plXUj10EZEQai 92upaGjw8V+GEwTe6Mj5sphaSVa7RNkFjA5+nqaFckpSQJp0hbWkgt1+TRWAs+Feyi3t0s5pXUM DUItppf0XTgz8hg5Q7BjmmXdSan+LsdrbqCv+gL1fKkaaFQQMpnBfZSMGkI0a5id1A0aJLrSxba 28HiHAq5VPrIMnNdB6h4vW6Fp X-Google-Smtp-Source: AGHT+IGtjMVs3u+ImLxlbz4wN/3vp0O1670lpwPPbaNXARxJdzrWzE0hK+LT3dlTusCo0Sa9oXEH9PZNe1dl0nPFBm0= X-Received: by 2002:a05:6a20:12d1:b0:350:7238:7e2e with SMTP id adf61e73a8af0-376aa6f90damr26248699637.45.1767006135616; Mon, 29 Dec 2025 03:02:15 -0800 (PST) Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 References: In-Reply-To: Date: Mon, 29 Dec 2025 12:02:03 +0100 X-Gm-Features: AQt7F2p74DpQnzLrfysRsU3622vjLNPqER9AHXEkmxFd7NbvyTr6gMSnVtWvxKY Message-ID: Subject: Re: [PHP-DEV] [Discussion] Reflection-based constructor autowiring (scope clarification) To: =?UTF-8?B?QU5EUsOBUyBab2x0w6FuIEd5w6FyZsOhcw==?= Cc: "internals@lists.php.net" Content-Type: multipart/alternative; boundary="0000000000000787960647152d5b" From: ocramius@gmail.com (Marco Pivetta) --0000000000000787960647152d5b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Zoli, On Sun, 28 Dec 2025 at 10:40, ANDR=C3=81S Zolt=C3=A1n Gy=C3=A1rf=C3=A1s wrote: > Hello internals, > > My name is Zolt=C3=A1n Gy=C3=A1rf=C3=A1s Andr=C3=A1s (aka Zoli). I am a l= ong-time PHP > developer, primarily working on large PHP codebases where constructor-bas= ed > 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 woul= d > 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 keep= s > 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 leve= l > 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 o= n > wiki.php.net that incorporates the feedback from this discussion. > > Thank you for your time and insights. > > Best regards, > > Zoli > I'm unconvinced about using reflection for this: reflection is thought of a "deep trap" for inspecting and manipulating code in ways that aren't generally possible in userland, and isn't really a factory. Everything you described can be implemented in userland, using existing reflection API. While I like the signature you are going with (or at least its direction), I believe that a userland implementation that proves to be "so popular that everyone would use it" is needed first. For instance, the implementation you propose already goes towards supporting DI systems that do autowiring at runtime, excluding those that do some AoT compilation of factories. Also, unless provided by resolvers, all dependencies aren't cached in any way (also something that tends to be configurable in various DI libraries). I suggest prroviding this as a userland library or extension first, specifically to validate whether there is a substantial performance improvement over current solutions. Marco Pivetta https://mastodon.social/@ocramius https://ocramius.github.io/ --0000000000000787960647152d5b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Zoli,

On Sun, 28 Dec 2025 at 10:40, ANDR=C3=81S Zolt=C3=A1n Gy=C3=A1rf=C3=A1s &= lt;azolee@gmail.com> wrote:
<= /div>

Hello intern= als,

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 w= here constructor-based dependency injection is used extensively.

Befo= re 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 ide= a is to introduce a=C2=A0minimal reflection-based constructor autowiring= primitive=C2=A0into the core, exposed explicitly via the Reflection AP= I, for example:

ReflectionClass::newInstanceAutowire(array $o=
verrides =3D [], ?callable $resolver =3D null): object

This proposal is intentionally narrow. To avoid misundersta= ndings, I would like to clearly explain what the idea=C2=A0does=C2= =A0and=C2=A0does not=C2=A0include.

Key points of the idea, = explained in detail:

1. Explicit opt-in (no change to the=C2= =A0new=C2=A0operator)
Autowiring would only happen when= the developer explicitly calls the new Reflection API.
The semantics of= the=C2=A0new=C2=A0operator remain unchanged. Existing code pa= ths are not affected, and there is no implicit dependency resolution anywhe= re 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 si= te and bound to the current call stack. No global state is created or reuse= d across calls.

3. No implicit interface-to-implementation mapping=
When a constructor depends on an interface or abstract class, the c= ore does not attempt to guess or discover a concrete implementation.
Suc= h mappings are inherently policy decisions and vary widely between framewor= ks. Instead, an explicit resolver callback is required if non-instantiable = types are involved.

4. Scalar parameters require overrides or defa= ults
Scalar and builtin parameters are treated as configuration valu= es. The core does not read environment variables, configuration files, or g= lobals.
As a result, scalar parameters must either have default values o= r be provided explicitly via the=C2=A0$overrides=C2=A0argument= .

5. Interface and abstract types require an explicit resolver cal= lback
Interfaces and abstract classes are never instantiated automat= ically.
If encountered during autowiring, the core either delegates reso= lution to the provided resolver callback or fails with a clear exception. T= his keeps architectural decisions firmly in userland.

6. Determini= stic circular dependency detection
Autowiring necessarily builds an = object graph. The proposal includes mandatory detection of circular depende= ncies within that graph.
When a cycle is detected, a deterministic and d= escriptive 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 obj= ect instances are cached, no lifetimes are managed, and no persistent or gl= obal caches are introduced.

At this stage, I am primarily interested = in feedback on whether this level of restraint is sufficient to keep the fe= ature aligned with PHP=E2=80=99s =E2=80=9Cmechanism, not policy=E2=80=9D ph= ilosophy, 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 di= scussion.

Thank you for your time and insights.

Best regards,

Zoli


I'm unconvinced abo= ut using reflection for this: reflection is thought of a "deep trap&qu= ot; for inspecting and manipulating code in ways that aren't generally = possible in userland, and isn't really a factory.
Everything = you described can be implemented in userland, using existing reflection API= .

While I l= ike the signature you are going with (or at least its direction), I believe= that a userland implementation that proves to be "so popular that eve= ryone would use it" is needed first.

For instance, the implementation y= ou propose already goes towards supporting DI systems that do autowiring at= runtime, excluding those that do some AoT compilation of factories.
<= div>Also, unless provided by resolvers, all dependencies aren't cached = in any way (also something that tends to be configurable in various DI libr= aries).

I s= uggest prroviding this as a userland library or extension first, specifical= ly to validate whether there is a substantial performance improvement over = current solutions.
=C2=A0
--0000000000000787960647152d5b--