Read-only properties/fields
Beste leden,
Is het in PHP mogelijk om velden ( properties ) als read-only in te stellen? Althans, om toegang tot te krijgen. Je hebt dus wel een Setter() nodig maar geen Getter(), dat je dus gewoon $object->property kunt gebruiken. Het enige is dan dat je dus niet: $this->property = new SomeObject(); kunt doen. Daar zou je dus de Setter() voor moeten gebruiken.. Iemand een ideetje?
Is het in PHP mogelijk om velden ( properties ) als read-only in te stellen? Althans, om toegang tot te krijgen. Je hebt dus wel een Setter() nodig maar geen Getter(), dat je dus gewoon $object->property kunt gebruiken. Het enige is dan dat je dus niet: $this->property = new SomeObject(); kunt doen. Daar zou je dus de Setter() voor moeten gebruiken.. Iemand een ideetje?
Gesponsorde koppelingen:
De property/fied private maken, en alleen een setter gebruiken.
Je bovenstaande bericht is wat verwarrend..
Je bovenstaande bericht is wat verwarrend..
Merijn Venema op 30/01/2012 21:24:06:
Is het in PHP mogelijk om velden ( properties ) als read-only in te stellen? Althans, om toegang tot te krijgen. Je hebt dus wel een Setter() nodig maar geen Getter(), dat je dus ...
Gewijzigd op 30/01/2012 22:46:22 door - Jim -
Ja dat werkt natuurlijk niet. Als iets private is is het niet buiten de klasse toegankelijk.
$object = new Object();
// moet wel kunnen
echo $object->property;
// moet niet kunnen
$object->property = "Some value";
$object = new Object();
// moet wel kunnen
echo $object->property;
// moet niet kunnen
$object->property = "Some value";
Ja, nee....
ik bedoel:
Een private property maken, en een getter:
ik bedoel:
Een private property maken, en een getter:
Code (php)
Gewijzigd op 30/01/2012 22:46:43 door - Jim -
Ja maar zoals ik het bedoel is dat een property dus read-only is. Buiten een getter om toegankelijk. In bijvoorbeeld C# kun je handig en snel Getters en Setters maken die te benaderen zijn als properties. Voordeel? Het scheelt 2 haakjes en het oogt netter.
$object->GetProperty() is minder mooi als $object->property. Enige nadeel is dat de property dus ook te overschrijven is op die manier. In een Set methode kun je nog wat feitjes controleren etc, maar hier is het gewoon klats-boem hupakee, overschrijven.
$object->GetProperty() is minder mooi als $object->property. Enige nadeel is dat de property dus ook te overschrijven is op die manier. In een Set methode kun je nog wat feitjes controleren etc, maar hier is het gewoon klats-boem hupakee, overschrijven.
Misschien dat je de magic __get en __set kunt overloaden:
http://php.net/manual/en/language.oop5.overloading.php
Ik denk dat je daar wel wat mee kunt, zie voornamelijk example #1
http://php.net/manual/en/language.oop5.overloading.php
Ik denk dat je daar wel wat mee kunt, zie voornamelijk example #1
Ah kijk, ik had al een grijs vermoeden. Maar is dat niet vrij traag? __get en __set zijn toch een beetje no-go methodes om te overloaden?
__get en __set traag? Dat is dan net zo traag als getPropertyName(). En deze magic methods zijn JUIST om te overloaden :)
Maar als je van een C/C++ achtergrond oid komt dan zullen 'magic methods' je wel vreemd klinken inderdaad, PHP is zowat de enige taal die zoiets implementeert.
Maar als je van een C/C++ achtergrond oid komt dan zullen 'magic methods' je wel vreemd klinken inderdaad, PHP is zowat de enige taal die zoiets implementeert.
Oke, dus eigenlijk is het vrij veilig om te implementeren? Heb het al even toegevoegd:
Je moet dan wel controleren of iets een read-only propertie is of niet (ik neem aan dat je niet alleen read-only properties hebt) en anders een Exception gooien:
Is wel een lelijke methode, maar ik zou niet weten hoe je het anders moet implenteren.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<?php
class Example
protected $foo;
protected $ro_bar;
public function __get( $name )
{
$name = ( substr($name, 0, 3) !== 'ro_' ? 'ro_'.$name : $name );
if( isset($this->$name) )
return $this->$name;
else
throw new LogicException('You don't have permission to get the propertie '.$name);
}
}
$example = new Example;
$example->foo; // throw exception
$example->bar; // give the value of bar
?>
class Example
protected $foo;
protected $ro_bar;
public function __get( $name )
{
$name = ( substr($name, 0, 3) !== 'ro_' ? 'ro_'.$name : $name );
if( isset($this->$name) )
return $this->$name;
else
throw new LogicException('You don't have permission to get the propertie '.$name);
}
}
$example = new Example;
$example->foo; // throw exception
$example->bar; // give the value of bar
?>
Is wel een lelijke methode, maar ik zou niet weten hoe je het anders moet implenteren.
Gewijzigd op 31/01/2012 21:32:03 door Wouter J
Hmm goed punt. Ja ik denk dat je inderdaad nog iets nodig moet hebben dat er voor zorgt dat het als een read-only property hanteerbaar is... Aan de andere kant.. Nee, je hebt gelijk. Misschien is het sowieso beter om gewoon getters te hanteren. Ik zie de bui we hangen dat je straks wachtwoorden of sleutels in je object opgeslagen hebt met een private modifier en ze toch leuk uit kunt lezen..
Hmm hier moet wat op te verzinnen zijn. Misschien een _ op het einde?
Hmm hier moet wat op te verzinnen zijn. Misschien een _ op het einde?
Gewijzigd op 31/01/2012 21:35:03 door Merijn Venema
Ik heb het nu geprobeerd met een ro_ in het begin (van read only). Maar misschien moet je nog een extra propertie aanmaken met de read only properties erin, of een var in de get functie:
Code (php)
Gewijzigd op 31/01/2012 21:55:23 door Wouter J
Ja ik had het door, maar vond dat iets te lelijk om door te voeren. Een underscore op het einde is ook niet mooi, maar valt nog wel te hanteren, enige wat je hoeft te doen is een extra character toevoegen.
Maar een array bijhouden is misschien ook nog wel iets. Jammer dat we geen keywords hebben die niet nodig zijn en kunnen hanteren en vervolgens checken of een property van type xx is... Ik denk dat ik voor een array ga. Enige nadeel is echter dat door het overloaden van de __get() je niet dynamisch velden kunt toevoegen en op kunt vragen, aangezien je niet dynamisch.. shit.. ik ben echt dom van tijd tot tijd..
Maar een array bijhouden is misschien ook nog wel iets. Jammer dat we geen keywords hebben die niet nodig zijn en kunnen hanteren en vervolgens checken of een property van type xx is... Ik denk dat ik voor een array ga. Enige nadeel is echter dat door het overloaden van de __get() je niet dynamisch velden kunt toevoegen en op kunt vragen, aangezien je niet dynamisch.. shit.. ik ben echt dom van tijd tot tijd..



