Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73853
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.215.10 cause and error)
To: Thomas Hruska <thruska@cubiclesoft.com>
Cc: PHP Development <internals@lists.php.net>
In-Reply-To: <5363AF7E.5040100@cubiclesoft.com>
References: <5363AF7E.5040100@cubiclesoft.com>
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 02 May 2014 17:07:51 +0200
Message-ID: <1399043272.5851.26.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Destructor best practice?
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

On Fri, 2014-05-02 at 07:45 -0700, Thomas Hruska wrote:
> ...
>    retval.handle = zend_objects_store_put(intern, 
> (zend_objects_store_dtor_t) zend_objects_destroy_object, 
> my_free_function_callback, NULL TSRMLS_CC);
> 
>    retval.handlers = zend_get_std_object_handlers();
> ...
> 
> In which 'my_free_function_callback' is the callback that frees 
> underlying structure information. 

This is guaranteed to be called *exactly* once.

>  The alternative is to use __destruct:
> 
> PHP_METHOD(my_class, __destruct)
> {
> }

This might be called and arbitrary number of times or might not be
called at all. (inherited classes might overwrite the dtor and not call
the parent; user might manually call $oject->__destruct() as they like)

> Which is considered best-practice?  I'm leaning toward the latter, but 
> want to make sure there aren't any issues with relying on the __destruct 
> approach.

My opinion is that __destruct() should "unset" the object state, as it
makes sense, it should exist (unless class is marked final) so users can
reliably call it from child classes. __destruct() should *not* destroy
internal object structures which leaves pointers around etc. but always
leave a defined state.

The dtor handler should do all required cleanup to ensure there are no
leaks etc. This mostly means cleaning up things the engine can't reach
otherwise (having "struct my_object { zend_object inner; my_ptr_t
*ptr; }" object->ptr should be cleaned up here)


johannes