Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:10238
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: Florian Schaper <fschaper@intux.org>
Cc: internals@lists.php.net
In-Reply-To: <007701c44832$8a399250$9d00a8c0@saiwala>
References: <005e01c447e6$9d28bf40$9d00a8c0@saiwala>
	 <Pine.LNX.4.58.0406011647260.28667@localhost>
	 <008001c447e7$d80ee9d0$9d00a8c0@saiwala>
	 <1086119310.281.43.camel@localhost>
	 <007701c44832$8a399250$9d00a8c0@saiwala>
Content-Type: text/plain
Message-ID: <1086138764.2776.76.camel@localhost>
Mime-Version: 1.0
Date: Tue, 01 Jun 2004 21:12:44 -0400
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] delete in PHP
From: adam@bregenzer.net (Adam Bregenzer)

On Tue, 2004-06-01 at 19:45, Florian Schaper wrote:
> For completeness:
> Proposed behaviour of delete as opposed to unset:
>  $ php-dev -r 'class Object { function __destruct() { echo
>  "Destroyed\n"; }} $o= new Object(); $o2= &$o; delete $o; var_export( $o );
> var_export( $o2 ); echo
>  "Shutting down\n";' Destroyed NULL NULL Shutting down

I could see this being useful, it certainly would make destructors much
more useful.  However, I think it is also unnecessary in a language like
PHP.  Additionally, since you can not be certain of the order
destructors are called in for objects when a script is terminated
(unless I missed a fix for this) it may cause an unhealthy dependence on
destructors.  This could end with people having to put a bunch of delete
calls at the end of their functions/scripts/etc. to guarantee everything
wraps up sanely.  I think this would be a very bad thing, not only
because it harbors memories of C/C++ but also because it would be
another confusing thing to teach new php OO coders.

> > 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.
[snip]
> I for one could manage without a delete keyword with unset destroying
> the object referenced - which looks for me a more consistent
> behaviour as Timm pointed out.

The operation of unset makes sense to me and should, imho, not change. 
It is used when you want to clear a particular variable of its contents,
not necessarily destroy the data; afaik it is similar to (if this were
valid):
$var =& null;
Looking at the examples and description in the manual[1] seems to
confirm this behavior in functions as well.  As a result, if you wanted
to use unset to delete an object you would have to unset every variable
that contains a reference to it, as it should be for unset.

In my PHP OO coding so far I have come across many instances where I
need unset's type of functionality.  One example of is in "poking holes"
in an array (ex. unset($arr['key']);).  If unset also went through and
destroyed every copy of that instance it would seem to me to be a very
unexpected and bad result.  Also, I can't work around it by setting the
array entry to null because the key would still exist.  If a method
similar to delete is needed I vote for it having its own name.  Possibly
inst_delete to reduce naming conflicts?

As a side note I have used count as a method name in a class before
without error.  I assume that since it is a method of a class it does
not conflict with the existing count[2] function, even though it may,
arguably, be bad coding style.

[1] http://www.php.net/unset
[2] http://www.php.net/count

-- 
Adam Bregenzer
adam@bregenzer.net
http://adam.bregenzer.net/