Hello Derick,

Sunday, July 20, 2003, 12:03:43 PM, you wrote:

DR> On Sun, 20 Jul 2003, Zeev Suraski wrote:

>> All in all, the destructor functionality is *extremely* fragile - to the 
>> degree that in many points in time we thought about removing it (you can 
>> look up the CVS archives to see just how many fixes it required so far - 
>> plenty).  Preventing access to resources may be something that we'd just 
>> have to live with.

DR> What is the point of having destructors then? I did a little quiz on IRC
DR> (yes, I know that that is not our typical userbase) and all of them
DR> mentioned that they wanted to use destructors to: "wrap up files",
DR> "commit a transaction", "do something with an open file", "really make
DR> sure my files are consistent". I am wondering what other use there is
DR> for constructors.

Singletons?

DR> Perhaps we should ditch them like namespaces because
DR> we can not come to a good implementation? I don't think that should be
DR> done, as destructors *can* be useful. Besides that I think it's totally
DR> uninituitive that:

DR> $obj = NULL;
?>>

DR> works and that the destructor than can access any resource it wants, but 
DR> that:

?>>

DR> doesn't work (because the destructor is called from request_shutdown).
DR> I'm pretty sure that there is some way to get this working in a decent 
DR> way... which might perhaps not be the nicest solution.

Fixing this is pretty easy. Simply do a third shutdown phase. And allow any
extension that requires such things to prepare shutdown before objects are
destroyed automatically. This will also ease resource shutdown management from
within c-level. So i am suggesting:

1) PShutdown: Things like session module
2) Destroy all vars and resources not yet destroyed in 1
3) RShutdown
4) shutdown memory manager and stuff
5) MShutdown

This is a very clean approach doesn't have BC problems and allows full
consistent destructor support.


Best regards,
 Marcus                            mailto:[EMAIL PROTECTED]


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to