[OOP] Self-destruct class
Is er een elegante oplossing om dit te beperken tot één expressie?
Ik heb er nu een vereenvoudigde observer tussen gezet, alleen zet dat in geheugengebruik geen zoden aan de dijk:
Code (php)
__destruct :3
Toevoeging op 07/06/2013 13:54:34:
Anyway, waarom wil je dat dan? Voor zo'n kleine class is het een beetje overdreven om alles te unsetten lijkt me..
Toevoeging op 07/06/2013 13:54:34:
Anyway, waarom wil je dat dan? Voor zo'n kleine class is het een beetje overdreven om alles te unsetten lijkt me..
Chris op 07/06/2013 13:53:23:
__destruct :3
Toevoeging op 07/06/2013 13:54:34:
Anyway, waarom wil je dat dan? Voor zo'n kleine class is het een beetje overdreven om alles te unsetten lijkt me..
Toevoeging op 07/06/2013 13:54:34:
Anyway, waarom wil je dat dan? Voor zo'n kleine class is het een beetje overdreven om alles te unsetten lijkt me..
Chris, dank je, maar helaas werkt het aanroepen van de eigen destructor met self::__destruct() of $this->__destruct() in een klasse niet: het object blijft bestaan en is nog steeds volledig functioneel. Ergens wel logisch, want __destruct() vernietigt een object niet, maar is meer bedoeld voor alles dat je daaraan voorafgaand nog wilt doen.
Het is inderdaad maar een kleinigheid. Maar ergens is deze onmogelijkheid niet logisch. Intuïtief zou je zeggen dat een klasse de eigen rommel moet kunnen opruimen. Nu ben je altijd afhankelijk van een externe garbage collector: meestal exit en soms unset().
Code (php)
Niet getest overigens, alleen een idee....
Ergens begrijp ik ook wel waarom een PHP-object zichzelf niet om zeep kan helpen: dat is de verantwoordelijkheid van de code die het ding in het leven heeft geroepen.
Destruct kan interessant zijn voor een GUI (bv. een windows programma).
Dat programma staat minuten lang te draaien; dan kan het interessant zijn om geheugen vrij te geven.
Maar php werkt gedurende een paar microseconde (of sneller). Maakt het dan uit of je de laatste 5 nanoseconden nog geheugen gaat vrij geven?
Kris Peeters op 07/06/2013 15:07:51:
Heeft dit allemaal zin?
Daar is iedereen het wel over eens hoor, denk ik, maar zeg nooit "nooit".
Ik heb bijvoorbeeld een grafische library die zo'n 8 seconden staat te stampen. Typisch iets dat je liever niet in PHP wilt programmeren. Typisch ook iets dat je niet voor een server wilt programmeren, omdat die zelden een fatsoenlijke GPU heeft.
O ja, daar heb je een punt.
Ik denk dat het voornamelijk logischer is om de daadwerkelijke variabelen die een hoop data bevatten te unsetten, dan objecten. Buiten dat, dit soort dingen zijn eigenlijk alleen van toepassing wanneer je een moeilijk groot php script hebt waar de gebruiker op zit te wachten tijdens het laden. Ik kan eigenlijk geen enkele logische manier verzinnen waarop dit écht noodzakelijk is. Zodra de pagina klaar is met laden, verwijdert PHP de garbage zelf en that's it. Einde proces toch?
Ward van der Put op 07/06/2013 14:57:33:
Ergens begrijp ik ook wel waarom een PHP-object zichzelf niet om zeep kan helpen: dat is de verantwoordelijkheid van de code die het ding in het leven heeft geroepen.
Klinkt als een auto laten ontploffen terwijl je er nog in zit. Nee eerst de auto verlaten en dan laten ontploffen anders kan je niet meer verder. zo werkt de computer ook. je kan geen geheugen vrijgeven van een programma dat nog zijn werk doet. heeft niets met php te maken want dat is in alle talen een heilige wet.
functies zijn er voor gemaakt om tijdelijke, onafhankelijke variabelen aan te maken welke ook weer om zeep geholpen worden als de functie verlaten wordt.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
<?php
class test {
var $name;
function __construct($name) {
$this->name = $name;
echo 'constructor '.$this->name.'<br/>';
}
function __destruct() {
echo 'destructor '.$this->name.'<br/>';
}
};
function dotest() {
$a = new test('test 1');
};
// bewaar het object in een variabele
$a = new test('test 2');
// maak het object en sla het niet op.
new test('test 3');
// maak het object aan in een functie
dotest();
echo 'einde van het programma<br/>';
?>
class test {
var $name;
function __construct($name) {
$this->name = $name;
echo 'constructor '.$this->name.'<br/>';
}
function __destruct() {
echo 'destructor '.$this->name.'<br/>';
}
};
function dotest() {
$a = new test('test 1');
};
// bewaar het object in een variabele
$a = new test('test 2');
// maak het object en sla het niet op.
new test('test 3');
// maak het object aan in een functie
dotest();
echo 'einde van het programma<br/>';
?>
output:
constructor test 2
constructor test 3
destructor test 3
constructor test 1
destructor test 1
einde van het programma
destructor test 2
Frank Nietbelangrijk op 07/06/2013 19:41:52:
Klinkt als een auto laten ontploffen terwijl je er nog in zit. Nee eerst de auto verlaten en dan laten ontploffen anders kan je niet meer verder. zo werkt de computer ook. je kan geen geheugen vrijgeven van een programma dat nog zijn werk doet. heeft niets met php te maken want dat is in alle talen een heilige wet.
Frank, leuke metafoor, maar die gaat niet altijd op. Bij multithreading / multiprocessing dicht op de kernel van een OS heb je een vergelijkbaar "fire and forget"-systeem. Je besteedt een proces uit terwijl je ondertussen iets anders doet. In PHP is dat ondenkbaar: alles is lineair en chronologisch, zelfs als je het OOP bouwt.
En vooral dat laatste zou een verrijking zijn: wat nu als we een taak kunnen uitbesteden aan een object, zonder dat we er verder hinder van ondervinden? Dan zouden we applicaties kunnen bouwen met processen die niet op elkaar hoeven te wachten! En dan zouden we webapplicaties hebben die in een fractie van een seconde meerdere dingen doen!
Maar helpen die threads zichzelf om zeep? ik denk het niet. Uiteindelijk moet de bovenste laag van het besturingssysteem toch weten welke resources in gebruik zijn en welke niet (meer).