Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124576
Precedence: bulk
MIME-Version: 1.0
References: <CAOWwgpmbq5VRrZQvUXDsKiNK4r6+bFA4VxnjQ_U=h8T9r0o3DA@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> <bddba996-3204-4130-af21-ea375eeeaf22@bastelstu.be>
In-Reply-To: <bddba996-3204-4130-af21-ea375eeeaf22@bastelstu.be>
Date: Wed, 24 Jul 2024 17:23:39 +0200
Message-ID: <CAOWwgpkrrADHJGBj_=_MQn4XbGSgv3W4MuRHtZj1Tri5xJWiKw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Lazy Objects
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: Rob Landers <rob@bottled.codes>, =?UTF-8?Q?Benjamin_Au=C3=9Fenhofer?= <kontakt@beberlei.de>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000abd648061dffddf0"
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000abd648061dffddf0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

Le jeu. 18 juil. 2024 =C3=A0 21:58, Tim D=C3=BCsterhus <tim@bastelstu.be> a=
 =C3=A9crit :

> Hi
>
> On 7/17/24 20:31, Nicolas Grekas wrote:
> > A bit unrelated to the above topic: we've further clarified the RFC by
> > addition restrictions to what can be done with lazy proxies. Namely, wh=
en
> > the factory returns an object from a parent class, we describe that
> adding
> > more on the proxy class would throw, and we also explain why. We also
> added
> > a restriction to prevent a proxy from having an overridden __clone or
> > __destruct when the factory returns a parent, and explained why again.
>
> Note that in the RFC you typoed it as '__destructor' ('or' suffix).
>
> > Please let us know if anyone has other concerns.
>
> I've replied regarding the cloning semantics in an earlier email.
>
> Regarding the `reset*()` methods even with the additional examples I
> remain unconvinced that this is not only necessary to work around
> existing design issues in userland libraries. However I guess that we
> will not reach an agreement here and I also do not consider myself the
> target audience of this RFC. I'm just here to find edge cases :-)
>
> Except for the cloning semantics I cannot find any obvious problems with
> the described semantics.
>


Cloning has kept us busy in the last days and after many brainstorming
sessions, we've decided to follow your initial proposal : make the clone
operator trigger the initialization of the original object before cloning
it.

The RFC is updated, with a note about "Lazy cloning" in the "Future scope"
section.

Since this should be the last topic in this thread, we plan to open the
vote on Friday.

I invite everybody to give the RFC a new read.

Thanks,
Nicolas

--000000000000abd648061dffddf0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,<br></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">Le=C2=A0jeu. 18 juil. 2024 =C3=A0=C2=A021:58,=
 Tim D=C3=BCsterhus &lt;<a href=3D"mailto:tim@bastelstu.be">tim@bastelstu.b=
e</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex">Hi<br>
<br>
On 7/17/24 20:31, Nicolas Grekas wrote:<br>
&gt; A bit unrelated to the above topic: we&#39;ve further clarified the RF=
C by<br>
&gt; addition restrictions to what can be done with lazy proxies. Namely, w=
hen<br>
&gt; the factory returns an object from a parent class, we describe that ad=
ding<br>
&gt; more on the proxy class would throw, and we also explain why. We also =
added<br>
&gt; a restriction to prevent a proxy from having an overridden __clone or<=
br>
&gt; __destruct when the factory returns a parent, and explained why again.=
<br>
<br>
Note that in the RFC you typoed it as &#39;__destructor&#39; (&#39;or&#39; =
suffix).<br>
<br>
&gt; Please let us know if anyone has other concerns.<br>
<br>
I&#39;ve replied regarding the cloning semantics in an earlier email.<br>
<br>
Regarding the `reset*()` methods even with the additional examples I <br>
remain unconvinced that this is not only necessary to work around <br>
existing design issues in userland libraries. However I guess that we <br>
will not reach an agreement here and I also do not consider myself the <br>
target audience of this RFC. I&#39;m just here to find edge cases :-)<br>
<br>
Except for the cloning semantics I cannot find any obvious problems with <b=
r>
the described semantics.<br></blockquote><div><br></div><div><br></div><div=
>Cloning has kept us busy in the last days and after many brainstorming ses=
sions, we&#39;ve decided to follow your initial proposal : make the clone o=
perator trigger the initialization of the original object before cloning it=
.</div><div><br></div><div>The RFC is updated, with a note about &quot;Lazy=
 cloning&quot; in the &quot;Future scope&quot; section.</div><div><br></div=
><div>Since this should be the last topic in this thread, we plan to open t=
he vote on Friday.</div><div><br></div><div>I invite everybody to give the =
RFC a new read.</div><div><br></div><div>Thanks,</div><div>Nicolas<br></div=
></div></div>

--000000000000abd648061dffddf0--