Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:10232
Return-Path: <thekid@thekid.de>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 79077 invoked by uid 1010); 1 Jun 2004 19:53:21 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 79038 invoked from network); 1 Jun 2004 19:53:21 -0000
Received: from unknown (HELO moutng.kundenserver.de) (212.227.126.184)
  by pb1.pair.com with SMTP; 1 Jun 2004 19:53:21 -0000
Received: from [212.227.126.179] (helo=mrelayng.kundenserver.de)
	by moutng.kundenserver.de with esmtp (Exim 3.35 #1)
	id 1BVFK5-0006Zn-00
	for internals@lists.php.net; Tue, 01 Jun 2004 21:53:21 +0200
Received: from [80.139.17.172] (helo=[80.139.17.172])
	by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1)
	id 1BVFK4-0006o0-00
	for internals@lists.php.net; Tue, 01 Jun 2004 21:53:20 +0200
To: internals@lists.php.net
In-Reply-To: <008001c447e7$d80ee9d0$9d00a8c0@saiwala>
References: <005e01c447e6$9d28bf40$9d00a8c0@saiwala>
	 <Pine.LNX.4.58.0406011647260.28667@localhost>
	 <008001c447e7$d80ee9d0$9d00a8c0@saiwala>
Content-Type: text/plain
Message-ID: <1086119310.281.43.camel@localhost>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Tue, 01 Jun 2004 21:48:31 +0200
Content-Transfer-Encoding: 7bit
X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:e958292ea7b1c44e51b2b9ca0a9da460
Subject: Re: [PHP-DEV] delete in PHP
From: thekid@thekid.de (Timm Friebe)

On Tue, 2004-06-01 at 16:50, Florian Schaper wrote:
> Derick Rethans wrote:
> > On Tue, 1 Jun 2004, Florian Schaper wrote:
> >
> >> An Zend API 2.0 paper I read a while ago said something about
> >> "delete" being implemented in PHP5.
> >> However, no delete.
> >>
> >> Was this feature dropped? I have implemented delete for myself now
> >> and was wondering if it was worth committing.
> >
> > unset($obj) works just fine too.
> >
> 
> My version of delete works like the delete we know from C++. The object's
> destructor and the object is then released immediately. All references of
> this object are set to IS_NULL.

In comparison to the proposed "delete", unset() only decreases the
refcount.

Have a look at the following examples:

$ php-dev -r 'class Object { function __destruct() { echo "Destroyed\n";
}} $o= new Object(); unset($o); echo "Shutting down\n";'
Destroyed
Shutting down

$ php-dev -r 'class Object { function __destruct() { echo "Destroyed\n";
}} $o= new Object(); $o2= $o; unset($o); echo "Shutting down\n";'
Shutting down
Destroyed

In the second example, the destructor is not called until *after*
shutdown. This is the small but noticeable difference between what
Florian wants and what we currently provide.

While I agree this could be interesting, I'm opposed to a keyword named
"delete". Keywords may not be used as regular method names and a new
keyword "delete" would add more BC breaks for people using methods
called delete(). This:

  class DBConnection {
    function insert() { }
    function update() { }
    function select() { }
    function delete() { }
  }

is an example which can be seen in numerous applications. 

Then again, why doesn't unset() do this? That seems kind of inconsistent
with the object-handle-pass-by-value semantics we have in PHP5.

For the time being, using reference operators and setting the instance
to NULL gives you a workaround:

$ php-dev -r 'class Object { function __destruct() { echo "Destroyed\n";
}} $o= new Object(); $o2= &$o; $o= NULL; echo "Shutting down\n";'
Destroyed
Shutting down

Interesting enough (from a user's pov, not the Engine's), unset() will
not do the job:

$ php-dev -r 'class Object { function __destruct() { echo "Destroyed\n";
}} $o= new Object(); $o2= &$o; unset($o); echo "Shutting down\n";'
Shutting down
Destroyed

(neither will omitting the & in the first solution).

- Ti "back to references after all?" mm