Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124444
Feedback-ID: ifab94697:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-568-g843fbadbe-fm-20240701.003-g843fbadb
Precedence: bulk
MIME-Version: 1.0
Message-ID: <a754568e-e94f-4f11-a56d-2a7a70fd27cc@app.fastmail.com>
In-Reply-To: <b388190c-7394-4981-a41d-125c09e94876@bastelstu.be>
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>
 <b388190c-7394-4981-a41d-125c09e94876@bastelstu.be>
Date: Tue, 16 Jul 2024 08:43:35 +0200
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>,
 =?UTF-8?Q?Benjamin_Au=C3=9Fenhofer?= <kontakt@beberlei.de>
Cc: "PHP Internals List" <internals@lists.php.net>,
 "Nicolas Grekas" <nicolas.grekas+php@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Lazy Objects
Content-Type: multipart/alternative;
 boundary=bd75815e63c8466c9eb7084bdc335f3a
From: rob@bottled.codes ("Rob Landers")

--bd75815e63c8466c9eb7084bdc335f3a
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 15, 2024, at 21:23, Tim D=C3=BCsterhus wrote:
> Hi
>=20
> On 7/12/24 08:00, Rob Landers wrote:
> > For what it=E2=80=99s worth, I see =E2=80=9CresetAsLazy()=E2=80=9D b=
eing most useful for unit testing libraries that build proxies. While th=
is feature will remove most of the tricky nuances around proxies, it doe=
sn=E2=80=99t make it any easier in generating the code for them, so that=
 has to be tested. Being able to write a test like this (abbreviated):
> >=20
> > $realObj =3D new $foo()
> > $proxy =3D clone $realObj;
> > makeTestProxy($proxy); // resets as lazy with initializer
> > assert($realObj =3D=3D $proxy);
> >=20
> > Is really simple. Without a reset method, this isn=E2=80=99t straigh=
tforward.
> >=20
>=20
> I'm not sure if I follow this example. With the native support for laz=
y=20
> objects there should no longer be a need for code generation, no?=20
> Testing that PHP works correctly in your own test suite is not a=20
> value-add, PHP has its own tests for that.
>=20
> Best regards
> Tim D=C3=BCsterhus
>=20

There are ghost objects, and then there are proxies. This RFC allows bot=
h. Beyond that, there are many types of proxies. For example, I have a l=
ibrary that proxies an interface or class, generates a spy proxy, and wh=
en the user calls those methods on it, it records these calls for asynch=
ronous RPC (for remote objects) or locally =E2=80=94 kinda like erlang.=20

This code obviously has to be tested, both the generation of the code, a=
s well as the execution. Now that properties can exist on interfaces, I =
also have to figure out how that will affect things as well, and test th=
at. Being able to defer generation and/or state hydration to actual usag=
e will be a massive improvement, especially in cases where you may have =
nested objects.

Now, you asked why I would want to test PHP=E2=80=99s own behavior? Well=
, it=E2=80=99s a new language feature. I=E2=80=99m going to test the hel=
l out of it, learn its edges, and make sure it works as advertised and m=
y use case. If I find any bugs, I will report them. If this feature had =
existed for years, I would probably still test it to make sure php upgra=
des don=E2=80=99t break expected behavior and it still works on lower PH=
P versions. Are you suggesting that I don=E2=80=99t need to have tests f=
or this, that PHP will never change this feature?

=E2=80=94 Rob
--bd75815e63c8466c9eb7084bdc335f3a
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 Mon, Jul 15,=
 2024, at 21:23, Tim D=C3=BCsterhus wrote:<br></div><blockquote type=3D"=
cite" id=3D"qt" style=3D""><div>Hi<br></div><div><br></div><div>On 7/12/=
24 08:00, Rob Landers wrote:<br></div><div>&gt; For what it=E2=80=99s wo=
rth, I see =E2=80=9CresetAsLazy()=E2=80=9D being most useful for unit te=
sting libraries that build proxies. While this feature will remove most =
of the tricky nuances around proxies, it doesn=E2=80=99t make it any eas=
ier in generating the code for them, so that has to be tested. Being abl=
e to write a test like this (abbreviated):<br></div><div>&gt;&nbsp;<br><=
/div><div>&gt; $realObj =3D new $foo()<br></div><div>&gt; $proxy =3D clo=
ne $realObj;<br></div><div>&gt; makeTestProxy($proxy); // resets as lazy=
 with initializer<br></div><div>&gt; assert($realObj =3D=3D $proxy);<br>=
</div><div>&gt;&nbsp;<br></div><div>&gt; Is really simple. Without a res=
et method, this isn=E2=80=99t straightforward.<br></div><div>&gt;&nbsp;<=
br></div><div><br></div><div>I'm not sure if I follow this example. With=
 the native support for lazy&nbsp;<br></div><div>objects there should no=
 longer be a need for code generation, no?&nbsp;<br></div><div>Testing t=
hat PHP works correctly in your own test suite is not a&nbsp;<br></div><=
div>value-add, PHP has its own tests for that.<br></div><div><br></div><=
div>Best regards<br></div><div>Tim D=C3=BCsterhus<br></div><div><br></di=
v></blockquote><div><br></div><div>There are ghost objects, and then the=
re are proxies. This RFC allows both. Beyond that, there are many types =
of proxies. For example, I have a library that proxies an interface or c=
lass, generates a spy proxy, and when the user calls those methods on it=
, it records these calls for asynchronous RPC (for remote objects) or lo=
cally =E2=80=94 kinda like erlang.&nbsp;<br></div><div><br></div><div>Th=
is code obviously has to be tested, both the generation of the code, as =
well as the execution. Now that properties can exist on interfaces, I al=
so have to figure out how that will affect things as well, and test that=
. Being able to defer generation and/or state hydration to actual usage =
will be a massive improvement, especially in cases where you may have ne=
sted objects.<br></div><div><br></div><div>Now, you asked why I would wa=
nt to test PHP=E2=80=99s own behavior? Well, it=E2=80=99s a new language=
 feature. I=E2=80=99m going to test the hell out of it, learn its edges,=
 and make sure it works as advertised and my use case. If I find any bug=
s, I will report them. If this feature had existed for years, I would pr=
obably still test it to make sure php upgrades don=E2=80=99t break expec=
ted behavior and it still works on lower PHP versions. Are you suggestin=
g that I don=E2=80=99t need to have tests for this, that PHP will never =
change this feature?<br></div><div><br></div><div id=3D"sig121229152">=E2=
=80=94 Rob<br></div></body></html>
--bd75815e63c8466c9eb7084bdc335f3a--