Hello Andi, Saturday, July 5, 2003, 12:55:09 AM, you wrote:
AG> At 09:30 PM 4/7/2003 +0200, Marcus Börger wrote: >>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) AG> You're getting a bit carried away. The only reason why I mentioned that AG> Java doesn't have destructors was that you made it sounds as if access AG> modifiers for destructors are crucial for OO development, which they are not. AG> I do think that destructors should *always* be callable when the engine AG> destroys an object. I don't think that it should start checking access AG> modifiers and printing out errors. As it is, destructors are a relatively AG> volatile feature (i.e. during a fatal error we can't call them). Adding to AG> the volatility with access modifiers is the wrong way to go in my opinion. AG> Andi Ok. Having destructors always being callabe during engine shutdown seems resonable (and acceptable) to me. What about having protected and private applied only during runtime then (when invoked from unset($obj) for example ? [ Besides. To ensure we are talking about the exact same details. Applying visibility to a destructor would in no way hinder object destruction at language level. what i want is to prevent the user function __destruct from being executed and during runtime i want to either prevent object destruction or emit an error when the call to the destructor itself was illegal or it was invoked with wrong access. In no way i want to hinder memory cleanup during shutdown. Of course not. - The warning my patch emits during shutdown is to show the user that he is doing something wrong - that he misuses some class design. ] Best regards, Marcus mailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
