Andi Gutmans wrote:
> [...] > > This has several implications: > > [...]
>
> 2. A *VERY* important implication is that you cannot, and must not rely in any way on the order of destruction during shutdown. It runs in no particular order. That means that by the time the destructor for your object $foo is called, a reference to some other object $bar may already be post-destruction. Note that it will still be 'intact' and accessible in the sense that if you access it - there won't be crashes. However, if this object does indeed have a destructor, it can be considered semantically wrong to touch this object at this point.
Doesn't that render more sophisticated cases of objects with constructors sort of unusable? I mean, any scheme like
class Wrapper: ctor: $this->m_resource=alloc_resource(); dtor: $this->m_resource=free_resource(); doWork(): do_this_and_that($this->m_resource);
class Client: ctor: $this->m_wrapper=new Wrapper(); dtor: $this->m_wrapper->doWork();
is inherently unsafe, unless I totally got your message wrong (apologies for potential confusion).
If you consider a common case such as the wrapper class wrapping a db connection or a file handle, and the client's destructor logging some "shutdown" message using that wrapper, I fail to realize how this would work with the given destructor scheme.
I'm not too familiar with the old destruction scheme, but wouldn't a destruction scheme in which not all object destructors are called still be superior to one which is completely non-deterministic in terms of shutdown order? Or probably better, how about at least trying to shutdown in reverse creation order (and for all cases for which that won't work, use the new non-deterministic scheme)?
> [...]
Cheers, Michael
PS: Apologies for obvious stupid remarks in this post, I'm sure I'm missing 1+ obvious issues
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
