Hi
On 11/7/25 20:36, Claude Pache wrote:
Indeed, and here is a proof (variation on the “Example showing reliable
resource management” of the RFC):
https://3v4l.org/KJaL1
Something like a `Disposable` interface as suggested in the Future scope
section, is probably the only way to make it reliable, and it ought to be part
of the RFC.
It is correct that Exceptions will capture parameters, but I don't agree
with the conclusion that this means that the “future scope” Disposable
interface is a *necessity*.
Exceptions will only capture the resource if it is passed to an external
function. In that case, the external function is already capable of
storing the resource somewhere else for future use. This means that the
code passing the resource elsewhere must already be prepared that it
might not close immediately.
In fact the callee might rely on being able to hold onto the resource
and it remaining valid. It would therefore be invalid for the caller to
forcibly close it - as I had also mentioned in my (first) reply to Arnaud.
The callee is also able to prevent the capturing of the lock in your
example, by moving it into a non-parameter local variable. Like this
(https://3v4l.org/tL5Yt):
$local_lock = $lock; unset($lock);
I'm not trying to say that this is obvious - I agree that Exceptions
capturing parameters is something that folks need to learn about - , but
it is a possible solution to this problem.
Given that I don't agree that Disposable is the solution to the
“Exception” issue, it's my responsibility to offer an alternative and I
would like to do this:
The addition of either an attribute or a marker interface for resource
objects that the backtrace capturing will observe - similarly to the
#[\SensitiveParameter] attribute. When an object is marked as a resource
object, then it will be wrapped into a WeakReference when the backtrace
is captured. As a result, the object will remain accessible for
backtrace processing / logging as long as it would still be alive if
there wasn't an Exception. But it will prevent the Exception from
unexpectedly extending the lifetime in other cases.
In addition I could imagine a WeakReference storing the class name of
the originally stored object as a “poor man's generic”, allowing folks
to learn which type of object was originally stored in the weak
reference, even when the original object is already gone.
Best regards
Tim Düsterhus
