On 28.09.2024 at 16:21, Jonathan Vollebregt wrote: >> Hmm, I wonder about the use-cases of userland destructors. It seems to >> me they are mostly useful for sanity checks, and maybe to close >> resources. Are there others? >> >> If not, I wouldn't worry much about the visibility of destructors, >> because resources are scheduled for replacement anyway. > > Besides closing resources and killing processes I've seen them store > data to disk for caching, remove temp files, call callbacks/dispatch > events, change state on other objects, dump stored errors to error_log > in a loop in an error handler...
Okay. My point is that you cannot know (unless there are no circular dependencies) *when* a destructor is called by the engine; it may be called during some GC run, or during the request shutdown sequence. As it's now, that happens pretty early during shutdown, but that *might* change when stream resources are converted to objects. So you cannot be absolutely sure that everything works as expected in destructors. This is a general issue for garbage collected languages; some of these have no destructors at all, for such reasons. > It looks like there's quite a lot of use-cases for them (Which can go > wrong if called twice) that don't necessarily require resources to be > involved Like I said, I wouldn't be particularly worried about clients calling a destructor manually (that's a bit different for the engine, since segfaultish conditions should be avoided). But I don't have a strong opinion about the visibility of destructors anyway. I'm fine with allowing protected constructors. Christoph
