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
[EMAIL PROTECTED]
http://adam.bregenzer.net/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
