Re: [PHP3] Re: [PHP4BETA] Re: [PHP3] OO
| From: | Zeev Suraski | Date: | Thu, 05 Aug 1999 00:28:37 +0000 |
| Subject: | Re: [PHP3] Re: [PHP4BETA] Re: [PHP3] OO | ||
| References: | 1 | Groups: | php.version4 |
| Request: | Send a blank email to php-version4+get-3129@lists.php.net to get a copy of this message | ||
I think I need to clear up why there'll be no destructors in PHP, regardless of whether you think they may make some things a bit more elegant (that said, I haven't followed the thread about register_shutdown_function() closely, but you can register as many shutdown functions as you wish, and they'll be executed in the order they were registered).
Ok, so why not add in destructors.
PHP is not an object oriented language. That's a fact. It has the notion of objects, which is much more defined and well-implemented in version 4.0 than it was in version 3.0, but it is still not an object oriented language. You would usually use objects to package functionality, but your program will almost never look like a typical object oriented language (i.e., a set of objects talking with each other). Instead, it would usually be a structured program, accessing functionality-implementing objects.
PHP 4.0 (which is our development platform, we won't put in any changes into version 3.0 anyway) implements transparent reference counting for any and all values in the system. That means that when you do $a = $b, you will (almost) never trigger an actual data copy, but rather, increase the reference count of the value $b points to by 1, and make $a point to it as well. That means quite a few variables may end up pointing at the same value. To be more accurate, there's almost no value in PHP that won't get its reference count bumped to 2 or more during the execution of its containing script.
How does that interfere with destructors? The answer is two-part. First, I described that to demonstrate that you cannot invoke a destructor function once the variable that points to the object in question is deleted - a zillion other variables may point to the same value. Which brings us to the second problem.
Why not just invoke the destructor when the reference count of the object hits zero? In a better world, that would be a valid solution. But we're here, and it's not. For technical reasons, in quite a few cases, values actually get duplicated and not just refcount-increased. That would mean a single instance of the object will duplicate, and two instances of the object, with two separate reference counts would exist in memory. When the first one hits zero - the destructor will be invoked. And then the second one would hit zero, and the destructor would be invoked again.
Solving that would force us to also introduce copy constructors; We won't do it for two main reasons - increased obscurity for non OO programmers, and the fact you will almost never actually want to duplicate resources in PHP anyway (you wouldn't want to duplicate an open SQL link or a transaction handle - the reference count problem is a technical problem that doesn't interest you much, and forcing you to implement a copy constructor makes no sense).
A final note - I'll look into making the shutdown functions accept arguments before PHP 4.0 Beta 3 (Beta 2 will be out within a few days). This way you won't have to use global variables - instead, you could do
class foo {
function foo()
{
register_shutdown_function("destructFoo", $this);
}
function destructFoo()
{
...} }; And destructFoo($object_handle) will be called on script shutdown. Zeev At 17:50 04/08/99 , Manuel Lemos wrote:
Hello Rasmus, On 04-Aug-99 18:14:59, you wrote:-- Zeev Suraski <zeev@zend.com> http://www.zend.com/ For a PGP public key, finger bourbon@netvision.net.ilWhy would you need more than one? With a little logic you can make that Because you may nedd to cleanup for completely unrelated parts of your scripts. function do all the cleanup you need. That's what I did to solve the problem then. Actually I even have built a registration table that would handle removing registration entries and would be able to pass context to each of the registered shutdown functions. One of the problems is that I had to resort to global variables. That's fine as long I don't use somebody else's code that uses the same global variable names. Another problem is if you borrow code that also sets registers a shutdown function overriding yours or vice versa. It may happen and you might not be aware of the clash if you don't study throughly the code you are borrowing. PHP could be more flexible here if you reckon that these situations might be problematic. Usually I don't borrow much code, but I am certain tha a lot of people that is not skilled enough just borrow code from everywhere to solve their problems and are not aware of these situations. Regards, Manuel Lemos Web Programming Components using PHP Classes. Look at: http://phpclasses.UpperDesign.com/?user=mlemos@acm.org -- E-mail: mlemos@acm.org URL: http://www.mlemos.e-na.net/ PGP key: http://www.mlemos.e-na.net/ManuelLemos.pgp -- -- PHP 3 Mailing List <http://www.php.net/> To unsubscribe, send an empty message to php3-unsubscribe@lists.php.net To subscribe to the digest, e-mail: php3-digest-subscribe@lists.php.net To search the mailing list archive, go to: http://www.php.net/mailsearch.php3 To contact the list administrators, e-mail: php-list-admin@lists.php.netI did not invent this situation. It happened to me while using PostgreSQL transactions. I had to resort to register_shutdown_function() to end any pending transactions. It worked but it was a lame solution even because register_shutdown_function only lets you register one function at a time and you might need more. There's another thing to be improved.