Hello Andi,
so now we will copy Java behavior? But why then have destructors at all? But since we have them why not allow visibility with destructors as all the other languages do which have destructors?
I came accross it when i wanted to force certain destruction ion behavior. I could define it as protected or private but the visibility was simply ignored. So i added a short fix for that and found out that the GC causes some trouble with that, which i solved by the patch applied here earlier.
Anyway if we were to disable visibility for destructors we'd need to do that in the compiler right where the function gets defined. Only it would be very strange to have visibility but do not have them always. And also when Java does not have destructors, why do we have destructors at all? Or isn't that an argument.
Friday, July 4, 2003, 10:16:11 PM, you wrote:
AG> At 07:29 PM 4/7/2003 +0200, Marcus Börger wrote: >>AG> I don't like these OO tricks. It makes sense in my opinion not to have >>AG> access modifiers for destructors. The destructor should be called on >>object >>AG> destruction no matter what. >> >>Hm, i think full language support for factories and related patterns are oo >>tricks that we should provide. At least i *very* much hope we do.
AG> I don't see any correlation between factories and design patterns and AG> allowing destructors to have access modifiers. Java doesn't even have AG> destructors :)
As i said already i came accross it. What you could do with it is to control the complete object lifecycle. And if GC causes a warning/error on an attempt to destruct an instance with a protected or private destructor it would help for building large scripts or scripts with long run times where many objects are used. It would help because just you can be forced to destruct the object in a certain way...one that does soem other work, too. And not all of these are possible with plain public destructors.
farwell, i'm out for a drink now (which i really need now)
You're getting a bit carried away. The only reason why I mentioned that Java doesn't have destructors was that you made it sounds as if access modifiers for destructors are crucial for OO development, which they are not.
I do think that destructors should *always* be callable when the engine destroys an object. I don't think that it should start checking access modifiers and printing out errors. As it is, destructors are a relatively volatile feature (i.e. during a fatal error we can't call them). Adding to the volatility with access modifiers is the wrong way to go in my opinion.
Andi
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
