Kan een object zichzelf vernietigen?
Als je nu vervolgens weer $class->doe_iets() zou aanroepen zou je een error moeten krijgen omdat het object niet meer bestaat.
Is dat mogelijk?
http://ca.php.net/manual/en/language.oop5.decon.php
Je moet kijken naar class destroy of destructors.
Gewijzigd op 19/11/2010 15:50:50 door Nicoow Unknown
op stackoverflow staat hierover ook een topic. Zoek op kamikase (geen idee hoe je het schrijft).
Nico Kaag op 19/11/2010 15:50:30:
Google al geprobeerd?
Pfff... ja natuurlijk. Wat dacht je zelf?
Het is me alleen tot op heden nog niet gelukt.
Het lastige is dat het om een functie gaat die zijn eigen class kapot moet maken. __destruct lijkt niks te doen. Iemand een goede suggestie?
Voor zover ik weet, is het niet mogelijk om deze verwijzingen te verwijderen.
Ik hoop dat ik het mis heb. Dat zou voor mij ook heel wat extra functionaliteit teweeg brengen.
Kun je een object aanmaken en toekennen aan een variabele en vervolgens het object zichzelf laten vernietigen zodat je met de variabele het object niet meer kan aanspreken.
En al op stackoverflow gekeken?
Kortom nog meer uitleg graag ;-)
@Niels:
Ik heb een database class. Uhmmm... hoe leg ik dit nu weer uit :-s
Door de get functie van de database aan te spreken kan ik een instantie van de database class ophalen die een eigen PDO verbinding bevat. Ik wil zo'n database kunnen afsluiten door de functie close te gebruiken. Deze functie killt de PDO verbinding. Dat gaat allemaal prima.
Maar stel je nu dit voor:
$database = Database::get{'test'};
$database->voerietsuit();
$database->close();
De database verbinding is nu gesloten, echter ik kan nog steeds de database instantie aanspreken en de functie voerietsuit() gebruiken. Dit gaat tot fouten leiden omdat de verbinding is afgesloten. Natuurlijk kan ik de variabele $database unsetten, maar dan moet ik telkens na het aanroepen van een close functie ook nog de variabele unsetten. Ik hoopte dat ik de betreffende instantie kapot kan maken in de close() functie, zodat $database->voerietsuit() totaal niet meer werkt.
Ik hoop dat je begrijpt wat ik bedoel :-/
Maar waarom zou je de verbinding willen sluiten? Als je hem niet meer nodig hebt, gebruik je het object toch niet meer? Misschien dat reflection iets voor je kan doen? Volgens mij kan je daarmee je object 'vernietigen'
Even een edit. Als je unset($object) doet, roept hij eerst de __destructor aan voordat het object wordt weggegooid. Dat is volgens mij dus een vervanger van $database->close() ?
Gewijzigd op 19/11/2010 21:26:13 door Niels K
Maar als ik het goed begrijp kan wat ik wil dus eigenlijk niet... hmmm, jammer...
In het verlengde hiervan.. ik heb in de database class een statische private array waarin ik de instanties van de database class opsla. Klinkt ingewikkeld maar valt nogal mee. Nu wordt er in mn framework altijd een default database verbinding gemaakt. Echter, ik wil niet dat je deze verbinding kan closen. Is het dan ook mogelijk om een functie in de class te unsetten? Lekker duidelijk dit, hahaha...
Voorbeeldje:
Database::set('default'); // doe iets waardoor de functie close() uit de class wordt gehaald
$database_default = Database::get('default');
$database_default->close(); // he, deze functie kun je nu niet aanroepen!
Database::set('zomaareendatabase);
$database_zomaar = Database::get('zomaareendatabase);
$database_zomaar->close(); // de database verbinding wordt gesloten
Even een edit. Als je unset($object) doet, roept hij eerst de __destructor aan voordat het object wordt weggegooid. Dat is volgens mij dus een vervanger van $database->close() ?
Moet ik dan in die __destruct wel eerst de PDO verbinding sluiten? Op zich zou dit kunnen, maar ik vind het aanroepen van een close functie wel veel mooier en gebruiksvriendelijker.
Gewijzigd op 19/11/2010 21:34:23 door Ozzie PHP
Code (php)
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
<?php
public function __destruct( )
{
$this->close();
// of
Framework_Registry::getInstance()->get('db')->close( );
}
?>
public function __destruct( )
{
$this->close();
// of
Framework_Registry::getInstance()->get('db')->close( );
}
?>
Genoeg keuze dus:) Een destructor kan gewoon bijna alles wat een andere methode kan.
Zelf vind ik $database->close() eigenlijk wel veel mooier.. maar tja, als het niet anders gaat dan dat.... dan heb ik denk ik weinig keus.
Moet je even mee spelen.
(had je mijn vraag over het unsetten van een specifieke functie nog gelezen? zie hierboven...)
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
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
<?php
class Database
{
private $connection;
public function __construct( ) {}
public function close( )
{
// Of what ever
return mysql_close( $database );
}
public function __destruct( )
{
// Methode aanroepe die closes
$this->close( );
// Of hierin
mysql_close( $database );
}
}
// Via registry
$registry = Registry::getInstance( );
$db = $registry->get( 'db' );
unset( $db ); // Nu wordt zover ik weet dus de destructor aangeroepen
?>
class Database
{
private $connection;
public function __construct( ) {}
public function close( )
{
// Of what ever
return mysql_close( $database );
}
public function __destruct( )
{
// Methode aanroepe die closes
$this->close( );
// Of hierin
mysql_close( $database );
}
}
// Via registry
$registry = Registry::getInstance( );
$db = $registry->get( 'db' );
unset( $db ); // Nu wordt zover ik weet dus de destructor aangeroepen
?>
Gewijzigd op 19/11/2010 22:18:34 door Niels K
Ik zet een standaard verbinding op, nou ja.. eigenlijk een standaard database class want de verbinding wordt pas gemaakt op het moment dat ik de database voor de 1e keer get. Pas dan maakt ie daadwerkelijk verbinding. Oke, waar was ik.. oh ja... een standaard database die heb ik nodig voor mn framework, bijvoorbeeld om routes en settings en dergelijk in te laden. Eigenlijk zal ik in de praktijk alleen deze verbinding gebruiken, maar mocht er sprake zijn van een 2e of 3e database dan kan ik via de database class gemakkelijk een extra database aanmaken....
Ok, dus wat is nu het probleem nog? behalve dat ik niet geheel achter je denkwijze sta?
Er is verder geen probleem, alleen wat ik zou willen kan blijkbaar niet.
Gewijzigd op 19/11/2010 22:54:14 door Niels K