Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124573
Feedback-ID: ifab94697:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-582-g5a02f8850-fm-20240719.002-g5a02f885
Precedence: bulk
MIME-Version: 1.0
Message-ID: <138f79e3-20cb-441f-8899-bdf40ef0868e@app.fastmail.com>
In-Reply-To: <2fd6d80d-a55c-4aad-aeee-6d07d4b930a1@app.fastmail.com>
References: 
 <CAOWwgpmbq5VRrZQvUXDsKiNK4r6+bFA4VxnjQ_U=h8T9r0o3DA@mail.gmail.com>
 <ab83af79-0669-47dd-a3cb-ab72327ae174@bastelstu.be>
 <CAP1Jc13JWVg99AULgzrGXcoCWJtJZGz+nr_VoyUocw8n5n5sfQ@mail.gmail.com>
 <1118bbcd-a7b4-47bf-bf35-1a36ab4628e1@bastelstu.be>
 <CAP1Jc11vNiazMRL8Y-4NcJhsEkg6kgFNKLymTGfEPYRv114oTA@mail.gmail.com>
 <45847b93-02bf-459f-bcd2-81ba35a12c24@bastelstu.be>
 <CAOWwgpnt77-Sybzc3hcnFEui9t8wAv03NAov4xCK9ib_VRZ0JA@mail.gmail.com>
 <46bd4098-2936-4e46-98e9-fe55118325c2@bastelstu.be>
 <CAOWwgpkCy++W1C2t0PnkZ71S8vq1B734ZNPGw2-OHjmrwO3L4A@mail.gmail.com>
 <61ab36bc-b045-452a-84e0-87367d4c680e@bastelstu.be>
 <CAEPJduk6m1gdPOrsXYbsc+RLuHeEBav3pGwQO+PHs4UGGqtzhg@mail.gmail.com>
 <07e065f2-8f64-4bad-9a98-51f4eaf63ddb@app.fastmail.com>
 <CAOWwgpngQtg2NRW6M6RwgSH+OS1iipewHBmM5c36P2MxQGX78A@mail.gmail.com>
 <2a0a4650-c2c5-4c6d-ad3a-25365b3391b2@bastelstu.be>
 <CAOWwgpm9FLy_SNt7HLtJh5sxtfwjZMMN6pOKioDqsJc+GgD-sA@mail.gmail.com>
 <CAOWwgpnwoPH_rkJreh8v+X8WagzcCJ_puT1RWC0c717GMj5Onw@mail.gmail.com>
 <CAOWwgp=uwDebrx-=H8yP1Dgwf9ji=v_qagw9aAxbDJcPvCqKNw@mail.gmail.com>
 <b096b1d3-4414-4b53-a3b0-3a87c8dd7ff3@app.fastmail.com>
 <CAOWwgp=88jWSR-roWTrkkgwVgQvLQYbkTGSGAr6ASPs6s7s_4g@mail.gmail.com>
 <2fd6d80d-a55c-4aad-aeee-6d07d4b930a1@app.fastmail.com>
Date: Wed, 24 Jul 2024 16:13:01 +0200
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Lazy Objects
Content-Type: multipart/alternative;
 boundary=91691daf5bcc4889b83c84650d766046
From: rob@bottled.codes ("Rob Landers")

--91691daf5bcc4889b83c84650d766046
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 24, 2024, at 16:02, Larry Garfield wrote:
> On Thu, Jul 18, 2024, at 7:12 AM, Nicolas Grekas wrote:
>=20
> >> Otherwise, I'm quite looking forward to this.
> >
> > =F0=9F=A4=9E
>=20
> Another thought that occurred to me.  Given how lightweight it *looks*=
 to be (may not actually be, but looks it), how much overhead would ther=
e be to having a compiled DI container that is lazy by default?  Just ma=
ke everything lazy with a fairly standard initializer or factory, unless=
 a specific case says you shouldn't.  That way you can use optional depe=
ndencies in a constructor pretty much at will with no overhead of needin=
g to create a chain of dependencies as a result.
>=20
> Would that be a bad idea for some reason, or would it actually work?
>=20
> (This doesn't really affect my vote, more just a thought that came up.)
>=20
> --Larry Garfield
>=20

I'm not convinced a DI container is possible at all with this implementa=
tion, see "surprising behaviors."

When you are building a DI container, you usually have *absolutely no id=
ea* what a user will return from a proxy. At most, you might know they a=
re returning SomeInterface or SomeBaseClass, but the user might return M=
yFancyClass that implements the interface or base class, which isn't all=
owed via this implementation. The type must be exactly the same or a par=
ent class:

> the factory of a lazy proxy is allowed to return an instance of the sa=
me class as the proxy, or of a parent class.
>=20
> Returning an instance of a sub-class is not allowed

=E2=80=94 Rob
--91691daf5bcc4889b83c84650d766046
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Wed, Jul 24,=
 2024, at 16:02, Larry Garfield wrote:<br></div><blockquote type=3D"cite=
" id=3D"qt" style=3D""><div>On Thu, Jul 18, 2024, at 7:12 AM, Nicolas Gr=
ekas wrote:<br></div><div><br></div><div>&gt;&gt; Otherwise, I'm quite l=
ooking forward to this.<br></div><div>&gt;<br></div><div>&gt; =F0=9F=A4=9E=
<br></div><div><br></div><div>Another thought that occurred to me.&nbsp;=
 Given how lightweight it *looks* to be (may not actually be, but looks =
it), how much overhead would there be to having a compiled DI container =
that is lazy by default?&nbsp; Just make everything lazy with a fairly s=
tandard initializer or factory, unless a specific case says you shouldn'=
t.&nbsp; That way you can use optional dependencies in a constructor pre=
tty much at will with no overhead of needing to create a chain of depend=
encies as a result.<br></div><div><br></div><div>Would that be a bad ide=
a for some reason, or would it actually work?<br></div><div><br></div><d=
iv>(This doesn't really affect my vote, more just a thought that came up=
.)<br></div><div><br></div><div>--Larry Garfield<br></div><div><br></div=
></blockquote><div><br></div><div>I'm not convinced a DI container is po=
ssible at all with this implementation, see "surprising behaviors."<br><=
/div><div><br></div><div>When you are building a DI container, you usual=
ly have&nbsp;<i>absolutely no idea</i> what a user will return from a pr=
oxy. At most, you might know they are returning SomeInterface or SomeBas=
eClass, but the user might return MyFancyClass that implements the inter=
face or base class, which isn't allowed via this implementation. The typ=
e must be exactly the same or a parent class:<br></div><div><br></div><b=
lockquote type=3D"cite"><div>the factory of a lazy proxy is allowed to r=
eturn an instance of the same class as the proxy, or of a parent class.<=
br></div><div><br></div><div>Returning an instance of a sub-class is not=
 allowed<br></div></blockquote><div><br></div><div id=3D"sig121229152">=E2=
=80=94 Rob<br></div></body></html>
--91691daf5bcc4889b83c84650d766046--