On Sat, Sep 28, 2024, at 16:46, Christoph M. Becker wrote: > 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’s undocumented, AFAIK, but the destructor behavior is pretty dependable atm. For example, local variables are almost always destructed at the end of the current (function) scope. I am not sure what streams have to do with GC, but I can’t see how streams would change this behavior. > > 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 > Destructors should (IMHO) be public. Not necessarily because they can be called, but classes with destructors hint at underlying behavior when destructed. For performance, you might want to defer that by retaining a reference. If a class has a hidden destructor, you have to go read the code to find it. That’s my 2¢ — Rob
