Hi,
Le jeu. 18 juil. 2024 à 21:58, Tim Düsterhus <[email protected]> a écrit :
> 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, when
> > 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