magic __get __set
Wie van jullie gebruikt wel eens de magic __get en __set methodes?
Ik denk erover om ze te gebruiken in m'n container, omdat dit...
echo $this->container->paths->private->library;
... me eigenlijk net wat mooier/handiger lijkt dan:
echo $this->container->get('paths')->private->library;
Op internet lees ik vaak dat je de magic __get en __set beter niet kunt gebruiken omdat ze vertragend zouden werken.
Ik heb zelf net een test gedaan met het verschil tussen een get() en __get() aanroep.
Bij een for loop van 1.000.000 echo's naar het scherm deed de get() method er ongeveer 1,8 seconde over en de __get() method ongeveer 1,95 seconde. Dat verschil valt op zich dus mee.
Nu is zo'n testje grappig, maar ik ben benieuwd of je er in de praktijk wel of niet iets van zal merken. Gebruikt iemand zelf hier de __get en __set methods, en zo ja... hoe bevalt dat?
In de betreffende container class heb ik maar 1 class property ingesteld, en verder dan alleen de __get en __set functie. Ik ben benieuwd naar jullie ervaringen.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<?php
class Gebruiker
{
private $Gebruikersnaam;
public function construct($gebruikersnaam)
{
$this->Gebruikersnaam = $gebruikersnaam;
}
}
/* Nieuwe gebruiker met een gebruikersnaam */
$g = new Gebruiker('Admin');
/**
* Deze aanroep van een ontoegankelijke eigenschap strandt in een
* Fatal Error: Cannot access private property Gebruiker::$Gebruikersnaam.
*/
echo $g->Gebruikersnaam;
?>
class Gebruiker
{
private $Gebruikersnaam;
public function construct($gebruikersnaam)
{
$this->Gebruikersnaam = $gebruikersnaam;
}
}
/* Nieuwe gebruiker met een gebruikersnaam */
$g = new Gebruiker('Admin');
/**
* Deze aanroep van een ontoegankelijke eigenschap strandt in een
* Fatal Error: Cannot access private property Gebruiker::$Gebruikersnaam.
*/
echo $g->Gebruikersnaam;
?>
Door de fatale fout stopt het script resoluut. Maar misschien wil je dat helemaal niet en kan het script ook in leven blijven bij een ongeldige aanroep. Je kunt __get() dan bijvoorbeeld zo aan het werk zettten:
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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<?php
class Gebruiker
{
private $Gebruikersnaam;
public function construct($gebruikersnaam)
{
$this->Gebruikersnaam = $gebruikersnaam;
}
public function __get($name)
{
return null;
}
}
/**
* De gebruikersnaam is nog steeds een ontoegankelijke eigenschap,
* maar een onschuldige fout wordt onderdrukt.
*/
$g = new Gebruiker('Admin');
echo $g->Gebruikersnaam;
?>
class Gebruiker
{
private $Gebruikersnaam;
public function construct($gebruikersnaam)
{
$this->Gebruikersnaam = $gebruikersnaam;
}
public function __get($name)
{
return null;
}
}
/**
* De gebruikersnaam is nog steeds een ontoegankelijke eigenschap,
* maar een onschuldige fout wordt onderdrukt.
*/
$g = new Gebruiker('Admin');
echo $g->Gebruikersnaam;
?>
Een magische methode zoals __get() wordt automatisch aangeroepen. Dat maakt magische methoden dus belangrijk voor alle aanroepen waarvoor je niet zelf expliciet een getter hebt geschreven. Dat geldt dan weer per definitie voor alle eigenschappen die geen getter hebben.
Ik zou __get() alleen niet gebruiken (of: misbruiken) om eigenschappen die je eerst als private of protected declareert alsnog toegankelijk te maken. Dan kun je de eigenschap beter public maken.
Ik wil het voor niet-gedefinieerde properties (bijv. configuratie-instellingen) gebruiken.
Bijv. ik wil een basis-url instellen in mijn container.
Dan wil ik dit doen:
$container->base_url = 'www.mijnsite.nl';
en om op te vragen
echo $container->base_url;
Ik wil hier de magic __get en __set voor gebruiken. Maar de vraag is of dat in de praktijk MERKBAAR vertragend werkt?
Ozzie PHP op 01/02/2013 11:27:11:
Maar de vraag is of dat in de praktijk MERKBAAR vertragend werkt?
Benchmarken....
En als je er zorgen over hebt gebruik je toch gewoon een 'custom magic getter':
Die laatste variant vind ik makkelijker werken (zie mijn 1e post), maar de vraag is of zoiets MERKBAAR vertragend kan werken. Weet iemand dat uit EIGEN ervaring?
Erwin H op 01/02/2013 11:34:52:
Benchmarken....
Waarom altijd anderen vragen als je het zelf gewoon kunt testen? Wat als je zo een antwoord krijgt van Kareltje 'ja dat is vertragend' en van Pietje 'nee hoor, ik merk er niets van'. Dan weet je nog geen donder. De enige die er werkelijk iets van kan zeggen ben jij, want jij kan het in JOUW situatie testen, met jouw omgeving en jouw classes. Zo moeilijk is het niet om het gewoon 100.000 keer uit te voeren en ervoor en erna een tijd te printen naar het scherm...
(en dus nog even op je eerste post reagerend, dan bedoel ik niet een test met alleen get of __get, maar in je volledige omgeving)
Gewijzigd op 01/02/2013 11:41:19 door Erwin H
$container->base_url = 'www.mijnsite.nl';
wilt kunnen gebruiken, volstaat:
public $base_url;
De magische methode __get() gebruik je namelijk om ontoegankelijke eigenschappen alsnog toegankelijk te maken óf om de toegang op een of andere manier te regelen (bijvoorbeeld voor foutafhandeling). Je kunt __get() niet zomaar vergelijken met een get() en er is nog een alternatief.
Vraag is ook of je met __get() of een get() nu niet iets probeert te bereiken dat via de constructor moet lopen: het zetten van de gewenste $this->base_url. En omdat het hier om een root-URI c.q. hostnaam in een multi-site omgeving gaat, lijkt me het sowieso kritiek genoeg om het aan een constructor toe te vertrouwen.
De strftime functie is niet PHP's snelste functie maar om deze uit te voeren neemt gemiddeld 0.0005 seconden in beslag (gemeten waarden op een niet al te snel systeem). Nu heb jij het verschil tussen twee functies die een stuk 'simpeler' zijn, dus zal dat verschil nauwelijks meetbaar laat staan merkbaar zijn.
@Ger: als je het niet erg vindt bepaal ik graag zelf m'n eigen tempo. Ik doe liever iets doordacht dan ondoordacht.
Ozzie PHP op 01/02/2013 13:27:48:
Een klasse waar je in kunt stoppen wat je maar wilt om het er later weer uit te kunnen halen, vind ik een OOP-nachtmerrie. Als je dat tot in het extreme doorvoert, is de uiterste consequentie namelijk dat je één klasse kunt gebruiken voor alles. En eigenlijk niet eens dat, want dan kun je elke applicatie of sessie gewone een lege container meegeven met $data = array() en daar alles instoppen.@ward: het gaat om een container die settings opslaat. Vantevoren weet je niet wat je erin stopt. Dat is het principe van zo'n container. Je kunt dus niet alles vantevoren 'predefinen'. Snap je het?
Uit je voorbeelden leid ik af dat je meer concreets weet: je wilt niet slechts willekeurige settings opslaan, maar het gaat concreet om basis-URL's en paden. Bouw dan liever iets concreets en formaliseer de logica in je klassen.
Ward van der Put op 01/02/2013 09:15:18:
Een belangrijk verschil tussen __get() en een eigen getter is dat __get() automatisch wordt aangeroepen bij een eigenschap die ontoegankelijk is. In dit voorbeeld is dat bijvoorbeeld private $Gebruikersnaam:
Door de fatale fout stopt het script resoluut. Maar misschien wil je dat helemaal niet en kan het script ook in leven blijven bij een ongeldige aanroep. Je kunt __get() dan bijvoorbeeld zo aan het werk zettten:
Een magische methode zoals __get() wordt automatisch aangeroepen. Dat maakt magische methoden dus belangrijk voor alle aanroepen waarvoor je niet zelf expliciet een getter hebt geschreven. Dat geldt dan weer per definitie voor alle eigenschappen die geen getter hebben.
Ik zou __get() alleen niet gebruiken (of: misbruiken) om eigenschappen die je eerst als private of protected declareert alsnog toegankelijk te maken. Dan kun je de eigenschap beter public maken.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<?php
class Gebruiker
{
private $Gebruikersnaam;
public function construct($gebruikersnaam)
{
$this->Gebruikersnaam = $gebruikersnaam;
}
}
/* Nieuwe gebruiker met een gebruikersnaam */
$g = new Gebruiker('Admin');
/**
* Deze aanroep van een ontoegankelijke eigenschap strandt in een
* Fatal Error: Cannot access private property Gebruiker::$Gebruikersnaam.
*/
echo $g->Gebruikersnaam;
?>
class Gebruiker
{
private $Gebruikersnaam;
public function construct($gebruikersnaam)
{
$this->Gebruikersnaam = $gebruikersnaam;
}
}
/* Nieuwe gebruiker met een gebruikersnaam */
$g = new Gebruiker('Admin');
/**
* Deze aanroep van een ontoegankelijke eigenschap strandt in een
* Fatal Error: Cannot access private property Gebruiker::$Gebruikersnaam.
*/
echo $g->Gebruikersnaam;
?>
Door de fatale fout stopt het script resoluut. Maar misschien wil je dat helemaal niet en kan het script ook in leven blijven bij een ongeldige aanroep. Je kunt __get() dan bijvoorbeeld zo aan het werk zettten:
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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<?php
class Gebruiker
{
private $Gebruikersnaam;
public function construct($gebruikersnaam)
{
$this->Gebruikersnaam = $gebruikersnaam;
}
public function __get($name)
{
return null;
}
}
/**
* De gebruikersnaam is nog steeds een ontoegankelijke eigenschap,
* maar een onschuldige fout wordt onderdrukt.
*/
$g = new Gebruiker('Admin');
echo $g->Gebruikersnaam;
?>
class Gebruiker
{
private $Gebruikersnaam;
public function construct($gebruikersnaam)
{
$this->Gebruikersnaam = $gebruikersnaam;
}
public function __get($name)
{
return null;
}
}
/**
* De gebruikersnaam is nog steeds een ontoegankelijke eigenschap,
* maar een onschuldige fout wordt onderdrukt.
*/
$g = new Gebruiker('Admin');
echo $g->Gebruikersnaam;
?>
Een magische methode zoals __get() wordt automatisch aangeroepen. Dat maakt magische methoden dus belangrijk voor alle aanroepen waarvoor je niet zelf expliciet een getter hebt geschreven. Dat geldt dan weer per definitie voor alle eigenschappen die geen getter hebben.
Ik zou __get() alleen niet gebruiken (of: misbruiken) om eigenschappen die je eerst als private of protected declareert alsnog toegankelijk te maken. Dan kun je de eigenschap beter public maken.
Lees je uberhaupt wel de vraag of kijk je alleen maar naar de titel?
@Ozzie ken je het try-it-and-see principe?
Gewijzigd op 01/02/2013 15:15:45 door Moose -
Moose - op 01/02/2013 15:13:49:
Een vraag anoniem beantwoorden met twee wedervragen waarvan één een sneer en één een algemeenheid is, hoe zal ik het zeggen... makkelijk?Lees je uberhaupt wel de vraag of kijk je alleen maar naar de titel?
@Ozzie ken je het try-it-and-see principe?
@Ozzie ken je het try-it-and-see principe?
Natuurlijk lees ik de vraag, met Ozzie heb ik een prima verstandhouding. Maar ik denk dat hij hier iets impliciets probeert te doen wat je beter expliciet kunt maken.
Ward van der Put op 01/02/2013 15:00:36:
Een klasse waar je in kunt stoppen wat je maar wilt om het er later weer uit te kunnen halen, vind ik een OOP-nachtmerrie. Als je dat tot in het extreme doorvoert, is de uiterste consequentie namelijk dat je één klasse kunt gebruiken voor alles. En eigenlijk niet eens dat, want dan kun je elke applicatie of sessie gewone een lege container meegeven met $data = array() en daar alles instoppen.
Hoewel ik je gedachtegang begrijp, ben ik het er niet helemaal eens.
Zelf heb ik bijvoorbeeld een klasse die voor elke applicatie de GET danwel POST waardes uitleest (en checkt). Daarbij is het uiteraard onmogelijk om van te voren alle mogelijke parameters voor te definieren. Je zal dus een methode moeten hebben om elke mogelijke parameter, variabel, uit te lezen. Daarvoor is de __get methode een optie, of een get() functie.
Een config container is een andere optie (die Ozzie hier volgens mij gebruikt) waarbij het ook zeer zeker nuttig is om met zo'n methode in plaats van voorgedefinieerde getters te werken.
Wat ik echter nooit, maar dan ook echt nooit zou doen is:
Ward van der Put op 01/02/2013 12:22:55:
public $base_url;
Daarmee leg je namelijk afhankelijkheden tussen klassen die je heel moeilijk weer kan veranderen. Als je later eens dat property weg wil halen dan kan je al je klassen langs om te zoeken naar die ene klasse die direct het property aansprak. Gebruik je getters dan is dat heel wat makkelijker op te vangen.
Ozzie, sorry dat ik het zeggen moet, maar je klinkt de laatste tijd een beetje geïrriteerd. Ik denk ook dat wij iets minder goed jou topics beantwoorden dan eerst. Weet je waardoor dat komt? Dat komt omdat je de laatste tijd alleen maar performance topics opent. Laat ik voorop stellen dat ik het extreem goed vind dat je eerst alles uitdenkt en je zorgen maakt over de gebruiksgemak van je applicatie, maar je kunt ook overdrijven. Het verschil in merkbare performance doe je niet met dit soort onbelangrijke dingen, je hier zorgen over maken is nutteloos. Het performance verschil doe je later. Eerst script je je hele applicatie (nadat je hem hebt uitgedacht). Grote kans dat je dan denkt, nou dit gaat eigenlijk best snel. Dan hoef je je geen zorgen meer te maken. Kleine kans dat je denkt, tjonge jonge wat gaat die langzaam. In dat geval ga je her en der een beetje brenchmarken en de echte grote dingen aanpakken, zoals het cachen van configuratie instellingen en het verwijderen van grote queries. Dit soort dingen ga je nooit merken en nee, ook niet als je straks een zeer succesvolle website hebt.
En je stelt de laatste tijd ook wel veel vragen die je 123 kunt opzoeken op google. Misschien handig om daar ook wat tijd in te steken (in het gebruik of in het leren te gebruiken).
Erwin H op 01/02/2013 15:47:36:
Wat ik echter nooit, maar dan ook echt nooit zou doen is:
Daarmee leg je namelijk afhankelijkheden tussen klassen die je heel moeilijk weer kan veranderen. Als je later eens dat property weg wil halen dan kan je al je klassen langs om te zoeken naar die ene klasse die direct het property aansprak. Gebruik je getters dan is dat heel wat makkelijker op te vangen.
Ward van der Put op 01/02/2013 12:22:55:
public $base_url;
Daarmee leg je namelijk afhankelijkheden tussen klassen die je heel moeilijk weer kan veranderen. Als je later eens dat property weg wil halen dan kan je al je klassen langs om te zoeken naar die ene klasse die direct het property aansprak. Gebruik je getters dan is dat heel wat makkelijker op te vangen.
Dat ben ik zeker met je eens. Alleen denk ik dat een gewillige setter die alles slikt en een vrijgevige getter die alles cadeau doet geen goed alternatief is:
Code (php)
Nu hebben we weliswaar private $data maar ook een getter die alles weggeeft. Beter? En passant hebben we het wiel opnieuw uitgevonden en de werking van een array nagebouwd. Beter?
Maar wat we ook hebben gedaan, is de basis leggen voor iets dat we later per se niet willen, bijvoorbeeld:
Code (php)
En dan het punt uit mijn eerste voorbeeld: je kunt een gerichte get() met specifieke functionaliteit niet zomaar vergelijken met de magische __get() met generieke functionaliteit. Natuurlijk kun je wel hun snelheid vergelijken, maar dan vergelijk je appels met peren.
Ward van der Put op 01/02/2013 16:47:53:
Dat ben ik zeker met je eens. Alleen denk ik dat een gewillige setter die alles slikt en een vrijgevige getter die alles cadeau doet geen goed alternatief is:
Dat ligt aan waar je het voor nodig hebt.
Ward van der Put op 01/02/2013 16:47:53:
Nu hebben we weliswaar private $data maar ook een getter die alles weggeeft. Beter? En passant hebben we het wiel opnieuw uitgevonden en de werking van een array nagebouwd. Beter?
Zonder meer beter, met het oog op de toekomst. Nu heb je het namelijk helemaal in de hand om je getter en setter aan te passen zoveel je wilt, zonder dat je er ooit een ander deel van je applicatie mee in gevaar brengt.
Ward van der Put op 01/02/2013 16:47:53:
En dan het punt uit mijn eerste voorbeeld: je kunt een gerichte get() met specifieke functionaliteit niet zomaar vergelijken met de magische __get() met generieke functionaliteit. Natuurlijk kun je wel hun snelheid vergelijken, maar dan vergelijk je appels met peren.
Wel als je die get() gebruikt voor alle waardes (dus get($name)). Dan is het net zo generiek als __get($name). Ik zie echt geen verschil ertussen.
Even als disclaimer, ik probeer niet te zeggen dat een generieke getter beter is dan een serie van specifieke getters voor vooraf benoemde properties. Als je van te voren weet welke properties je hebt, dan is het maken van specifieke getters voor elk property vanuit alle punten beter wat mij betreft. Het gaat nu juist om de momenten waarop dat dus niet mogelijk is.
Erwin H op 01/02/2013 16:53:54:
Wel als je die get() gebruikt voor alle waardes (dus get($name)). Dan is het net zo generiek als __get($name). Ik zie echt geen verschil ertussen.
Ward van der Put op 01/02/2013 16:47:53:
En dan het punt uit mijn eerste voorbeeld: je kunt een gerichte get() met specifieke functionaliteit niet zomaar vergelijken met de magische __get() met generieke functionaliteit. Natuurlijk kun je wel hun snelheid vergelijken, maar dan vergelijk je appels met peren.
Wel als je die get() gebruikt voor alle waardes (dus get($name)). Dan is het net zo generiek als __get($name). Ik zie echt geen verschil ertussen.
Een get() moet je gericht aanroepen, een __get() wordt als magische methode automatisch aangeroepen zodra je een eigenschap aanroept die je eerder met private of protected ontoegankelijk hebt verklaard. Het ene is een positive, het andere een false negative. Min keer min is inderdaad ook plus, maar het is toch niet hetzelfde.
En dat is een wezenlijk verschil: de methode __get() wordt automatisch afgevuurd zodra eigenschappen worden benaderd waartoe je eerder toegang verboden hebt. Dat maakt __get() een onlogische keuze: met toegang tot eigenschappen die ontoegankelijk zijn verklaard, ondermijn je mogelijk je objectmodel. En die toegang is nog tweederangs ook: de magische methode __get() wordt pas afgevuurd nadat de toegang is geweigerd.
Wouter J op 01/02/2013 17:47:48:
Dat verandert de argumentatie toch niet?Ward, de __get() wordt ook aangeroepen als de propertie niet bestaat.
En dat bedoel ik zeker niet als een scheldwoord, dat ben ik zelf namelijk ook...
Ok, ja, de manier waarop de get() functie zou worden aangeroepen is anders dan de manier waarop de __get() functie wordt aangeroepen, zonder meer. Vraag is, heeft dat bepaalde consequenties?
Waar ik echter vind dat je te ver gaat is bij deze twee opmerkingen:
Ward van der Put op 01/02/2013 17:38:46:
zodra je een eigenschap aanroept die je eerder met private of protected ontoegankelijk hebt verklaard.
...
een onlogische keuze: met toegang tot eigenschappen die ontoegankelijk zijn verklaard
...
een onlogische keuze: met toegang tot eigenschappen die ontoegankelijk zijn verklaard
Dat is strict genomen misschien waar (kijkende naar private/protected/public), maar welk toegangsniveau wordt gegeven is voor mij totaal niet afhankelijk van wie het mag zien. Dat toegangsniveau is voor mij (voor een property) altijd private simpelweg omwille van de robuustheid van je applicatie. Toegang wordt geregeld door het wel of niet hebben van een getter danwel setter. Sterker, ik kan ook een getter of setter hebben voor een property dat fysiek helemaal niet bestaat. Bovenstaande opmerkingen vind ik dus enigszins overdreven.