Le lun. 15 juil. 2024 à 21:42, Tim Düsterhus <t...@bastelstu.be> a écrit :
> Hi > > On 7/15/24 09:25, Nicolas Grekas wrote: > > Testing is actually a good domain where resetting lazy objects might open > > interesting use cases. > > This reminded me about zenstruck/foundry, which leverages the > > LazyProxyTrait to provide refreshable fixture objects > > < > https://symfony.com/bundles/ZenstruckFoundryBundle/current/index.html#auto-refresh > > > > and provides nice DX thanks to this capability. > > > > I have not used this library before, but I have taken a (very) brief > look at the code and documentation. > > My understanding is that all the fixture objects are generated by a > corresponding Factory class. This factory clearly has the capability of > constructing objects by itself, so it could just create a lazy proxy > instead? > > I'm seeing the `instantiateWith()` example in the documentation where > the user can return a constructed object themselves, but I'm not seeing > how that can safely be combined with the `reset*()` methods: Anything > special the user did to construct the object would be reverted, so the > user might as well rely on the default construction logic of the factory > then. > > What am I missing? > Finding the spot where the reset method would be useful is not easy. Here it is: https://github.com/zenstruck/foundry/blob/v2.0.7/src/Persistence/IsProxy.php#L66-L76 Basically, the reset method is not needed when creating the lazy proxy. But it's needed to refresh it when calling $object->_refresh(). The implementation I just linked swaps the real object bound to the proxy for another one (the line "Configuration::instance()->persistence()->refresh($object);" swaps by reference).
