Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Final solution to destructor visibility? »

Final solution to destructor visibility?

php.internals

(Marcus Börger)

23 years ago
Hello Zeev, hi Andi, attached is my idea of finally fixing the destructor visibility. It simply emits an E_ERROR on an illegal attempt to destruct an object during execution and emits an E_WARNING with a slighlty longer message in shutdown (outside execution). Patch attached.
-- Best regards, Marcus mailto:helly@php.net

Andi Gutmans

23 years ago
Maybe we should just not allow access modifiers for the destructor. It doesn't make very much sense and we don't "promise" destruction at a specific point in time. Andi At 03:07 PM 3/7/2003 +0200, Marcus Börger wrote:

(Marcus Börger)

23 years ago
Hello Andi, Friday, July 4, 2003, 1:35:58 AM, you wrote: AG> Maybe we should just not allow access modifiers for the destructor. It AG> doesn't make very much sense and we don't "promise" destruction at a AG> specific point in time. On one hand it would of course be an option which simplifies our source (a few lines less code). But on the other hand it would disallow some nice oo tricks. And as the solution shows we could have at least one good working solution. Best regards, Marcus mailto:helly@php.net

Andi Gutmans

23 years ago
At 12:55 AM 4/7/2003 +0200, Marcus Börger wrote:
>Hello Andi, > >Friday, July 4, 2003, 1:35:58 AM, you wrote: > >AG> Maybe we should just not allow access modifiers for the destructor. It >AG> doesn't make very much sense and we don't "promise" destruction at a >AG> specific point in time. > >On one hand it would of course be an option which simplifies our source (a few >lines less code). But on the other hand it would disallow some nice oo tricks. >And as the solution shows we could have at least one good working solution.
I don't like these OO tricks. It makes sense in my opinion not to have access modifiers for destructors. The destructor should be called on object destruction no matter what. Andi

(Marcus Börger)

23 years ago
Hello Andi, Friday, July 4, 2003, 10:52:45 AM, you wrote: AG> At 12:55 AM 4/7/2003 +0200, Marcus Börger wrote:
>>Hello Andi, >> >>Friday, July 4, 2003, 1:35:58 AM, you wrote: >> >>AG> Maybe we should just not allow access modifiers for the destructor. It >>AG> doesn't make very much sense and we don't "promise" destruction at a >>AG> specific point in time. >> >>On one hand it would of course be an option which simplifies our source (a few >>lines less code). But on the other hand it would disallow some nice oo tricks. >>And as the solution shows we could have at least one good working solution.
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. Sometimes it is necessary to explicitly destruct an object and bla bla.... Btw. have a look at tests/classes/destructor_and_globals.phpt and make the destuctor protected or private with and without my patch. Beides that the situation is somekind of a more 'funny' problem we should fix it sometime.
-- Best regards, Marcus mailto:helly@php.net

Andi Gutmans

23 years ago
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.
I don't see any correlation between factories and design patterns and allowing destructors to have access modifiers. Java doesn't even have destructors :) Anyway, as I mentioned before, destructors shouldn't have access modifiers (like methods in interfaces). So what you are saying is that today we can make destructors private/protected? If so we need to fix it. Andi

(Marcus Börger)

23 years ago
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. AG> Anyway, as I mentioned before, destructors shouldn't have access modifiers AG> (like methods in interfaces). So what you are saying is that today we can AG> make destructors private/protected? If so we need to fix it. AG> Andi
>>Sometimes it is necessary to explicitly destruct an object and bla bla.... >>Btw. have a look at tests/classes/destructor_and_globals.phpt and make the >>destuctor protected or private with and without my patch. Beides that the >>situation is somekind of a more 'funny' problem we should fix it sometime. >> >> >>-- >>Best regards, >> Marcus mailto:helly@php.net
farwell, i'm out for a drink now (which i really need now) marcus

Andi Gutmans

23 years ago
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)
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

(Marcus Börger)

23 years ago
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:helly@php.net