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.
./regards
Florian
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.
regards,
Derick
Derick Rethans 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.
Some might argue that this is a feature not worth having if you have an
garbage collector but I can think about a few uses.
./regards
Florian
Derick Rethans 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
Timm Friebe wrote:
[...]
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
DestroyedIn 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.
I really dont't want to warm up an discussion that has already been dealt
with,
but from my pov. - while I agree one should keep them to a minimum - minor
changes are
to be excpected in a major jump in version numbers and I'm sure this is not
unprecedented. Then again I don't get the eMails from the developers
going on about their broken code and I wouldn't want to volunteer for that.
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
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
toNULLgives 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 downInteresting 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
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.
./regards
Florian
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";' DestroyedNULLNULL 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/