[php] onthoudt variable niet

[Saven]

Hi daar, wellicht doe ik wat verkeerds maar ik zou niet weten wat.
Ik heb een klasse waarin ik via een functie set_value() een object variable set, en met get_value() die waarde ophaal:

PHP:

class foo
{
    private $x = false;
    
    private function set_x($val)
    {
        $this->x = $val;
    }
    
    public function get_x()
    {
        return $this->x;
    }
    
    public function prepare($something)
    {
        $this->dodo($something);
    }
    
    private function dodo($lala)
    {
        $this->set_x('shalala');
        
        //echo $this->get_x();
        //geeft nu shalala terug
    }
}

Als ik nu in een ander bestand deze klasse wil gebruiken, en ik de prepare() functie uitvoer, krijg ik daarna niks terug uit de get_x() functie.

Voorbeeld:

PHP:

require_once('foo.class.php');
$foo = new foo();

$foo->prepare('nothingspecial');

echo $foo->get_x(); //geeft nu niks terug??

^{(let op de comments ter verduidelijking van mijn verhaal)}

Ik snap er niks meer van. De get_x() wordt toch echt geset, want in de klasse zelf kan ik hem nog opvragen. Maar nu ik hem buiten de klasse opvraag krijg ik niks terug?
Wie weet wat ik fout doe?

[Verwijderd]

private x = false;

moet je veranderen in
private $x = false;

[orf]

En is "do" niet een reserved keyword?
Sowieso om met error_reporting te werken. Dan haal je dit soort fouten er direct zelf uit.

[StM]

Jup, ik denk dat die hele code gewoon stopt met een Fatal Error...

[C0rnelis]

Bovenstaande comments zijn beide correct!

Bij het runnen van je code krijg je twee meldingen:

code:

// eerst
syntax error, unexpected 'x' (T_STRING), expecting variable (T_VARIABLE)
// daarna
syntax error, unexpected 'do' (T_DO), expecting identifier (T_STRING)

[Saven]

Sorry jongens het ging om het idee, heb dit even hier uit de pols getypt. Heb de typefoutjes aangepast

[StM]

Dan zou het gewoon moeten werken

[hylke94]

Als je nou deze regel:
private $x = false;
veranderd in:
private $x = 'test';

Krijg je dan wel iets terug? Misschien dat hij vast loopt, omdat de functie 'false' terug geeft.

[Saven]

Hmm in deze testcase werkt het inderdaad wel. Misschien komt het omdat ik die prepare() functie aanroep via een extended class:

PHP:

class xx extends foo
{
    public function doxx($lala)
    {
        return parent::prepare($lala);
    }
}

[Verwijderd]

is de functie dan wel protected? anders kan de parent er niet bij. is natuurlijk public

[ Voor 24% gewijzigd door Verwijderd op 05-05-2013 15:03 ]

[StM]

Maak $x eens protected ipv private

[Barryvdh]

Misschien moet je anders een test-case plaatsen waarbij het probleem ook echt optreedt, in plaats van voorbeeld stukjes.

[4Real]

Saven schreef op zondag 05 mei 2013 @ 15:01:
Hmm in deze testcase werkt het inderdaad wel. Misschien komt het omdat ik die prepare() functie aanroep via een extended class:

PHP:

class xx extends foo
{
    public function doxx($lala)
    {
        return parent::prepare($lala);
    }
}

Dit mag niet, want je parent class functie is geen static functie, daarbij wordt er ook nog $this in die functie gebruikt.

edit:
Te vluchtige conclusie, helemaal de plank misgeslagen

[ Voor 7% gewijzigd door 4Real op 06-05-2013 13:43 ]

[Verwijderd]

In C++ is parent::prepare() valide syntax, als de klasse tenminste afstamt van parent en deze een prepare() functie bevat. Ik weet niet hoe uitgebreid de objecten in php zijn maar het lijkt mij dat er ook wel een dergelijke construct bestaat. prepare() hoeft daarvoor niet noodzakelijk static te zijn.

[PatrickH89]

4Real schreef op maandag 06 mei 2013 @ 07:50:
[...]

Dit mag niet, want je parent class functie is geen static functie, daarbij wordt er ook nog $this in die functie gebruikt.

Dit is niet waar, in deze is parent:: geen static call. $this mag je dus gewoon gebruiken.

[4Real]

PatrickH89 schreef op maandag 06 mei 2013 @ 10:01:
[...]


Dit is niet waar, in deze is parent:: geen static call. $this mag je dus gewoon gebruiken.

Correct, ik had het even bij het verkeerde einde. Lokaal heb ik het script nog even uitgetest, maar hij doet precies wat TS wil en ik snap even niet wat er nou verkeerd gaat.

[Guillome]

StM schreef op zondag 05 mei 2013 @ 15:03:
Maak $x eens protected ipv private

Dit is het antwoord

[.oisyn]

Het antwoord op een vraag die niet gesteld is zeker? Waarom moet $x protected zijn? Hij wordt toch niet benaderd vanuit een subklasse?

@Saven: zoals iemand anders al zei, post het stuk code waarbij het probleem daadwerkelijk optreedt, want nu is het alleen maar giswerk. En dan bedoel ik niet letterlijk je huidige code posten, maar een simpele testcase proberen te isoleren aan de hand van de oorspronkelijke code.

[ Voor 51% gewijzigd door .oisyn op 06-05-2013 15:04 ]

[Cartman!]

Als het een probleem is met scope zou je op zn minst een notice moeten krijgen dat $x niet bestaat. Het lijkt me idd handig als de TS een uitgekleed voorbeeld maakt waarin dit fout gaat.

[BoringDay]

PHP:

<?
 
class foo 
{ 
    private $x = false; 
     
    private function set_x($val) 
    { 
        $this->x = $val; 
    } 
     
    public function get_x() 
    { 
        return $this->x; 
    } 
     
    public function prepare($something) 
    { 
        $this->dodo($something); 
    } 
     
    private function dodo($lala) 
    { 
        $this->set_x($lala); 
    } 
} 


 $obj = new foo;
 
 $obj->prepare('ik peuter in mijn neus');
 $neus = $obj->get_x();

 echo $neus;

Dit werkt hier ...
foo() moet foo zijn anders denkt php je een functie aanroept.

Als je met objecten/classes werkt kijk dan altijd even of het object is aangemaakt

PHP:

  if (isset($obj)) { echo 'mijn object bestaat'; } else { var_dump($obj); }

Zo voorkom je dat je iets wil aanspreken wat niet bestaat.

[ Voor 22% gewijzigd door BoringDay op 07-05-2013 20:47 ]

[4Real]

BoringDay schreef op dinsdag 07 mei 2013 @ 20:33:

Als je met objecten/classes werkt kijk dan altijd even of het object is aangemaakt

PHP:

  if (isset($obj)) { echo 'mijn object bestaat'; } else { var_dump($obj); }

Zo voorkom je dat je iets wil aanspreken wat niet bestaat.

Je wordt vanzelf wel afgestraft door de server, dan werkt je script niet.

Dit krijg je dan als error:

code:

Notice: Undefined variable: obj in C:\xampp\htdocs\obj-test.php on line 4

Fatal error: Call to a member function GetFunction() on a non-object in C:\xampp\htdocs\obj-test.php on line 4

Voor de zekerheid zet ik error_reporting ook altijd op E_ALL, zodat hij lekker streng mag zijn.

[epic007]

PHP:

class foo  
{  
    private $x = false;  
      
    private function set_x($val)  
    {  
        $this->x = $val;  
    }  
      
    public function get_x()  
    {  
        return $this->x;  
    }  
      
    public function prepare($something)  
    {  
        $this->dodo($something);  
    }  
      
    private function dodo($lala)  
    {  
        $this->set_x($lala);  
    }  
}  

class bar extends foo
{
    public function doxx($lala) 
    { 
        return parent::prepare($lala); 
    }
}

$obj = new bar();
$obj->doxx("aaaa");
echo $obj->get_x();

Werkt hier prima!

[BoringDay]

4Real schreef op woensdag 08 mei 2013 @ 09:40:
[...]
Je wordt vanzelf wel afgestraft door de server, dan werkt je script niet.

Dit krijg je dan als error:

code:

Notice: Undefined variable: obj in C:\xampp\htdocs\obj-test.php on line 4

Fatal error: Call to a member function GetFunction() on a non-object in C:\xampp\htdocs\obj-test.php on line 4

Voor de zekerheid zet ik error_reporting ook altijd op E_ALL, zodat hij lekker streng mag zijn.

Dat kan wel zijn maar dat is niet de juiste methode.
Namelijk als je objecten aanmaakt dien je ze ook weer vrij te geven en te valideren of het object wel bestaat voordat je het aanspreekt. Zo werkt OOP eenmaal en bij volledige programmeertalen ontkom je daar niet aan.
PHP heeft een beetje half gebakken OOP ondersteuning.

[P.O. Box]

.oisyn schreef op maandag 06 mei 2013 @ 15:03:
Het antwoord op een vraag die niet gesteld is zeker? Waarom moet $x protected zijn? Hij wordt toch niet benaderd vanuit een subklasse?

volgens wordt hij wel uit een subklasse benaderd, dus is dat wel het antwoord m.i.:

Saven schreef op zondag 05 mei 2013 @ 15:01:
Hmm in deze testcase werkt het inderdaad wel. Misschien komt het omdat ik die prepare() functie aanroep via een extended class:

PHP:

class xx extends foo
{
    public function doxx($lala)
    {
        return parent::prepare($lala);
    }
}

[.oisyn]

BoringDay schreef op woensdag 08 mei 2013 @ 16:31:
Namelijk als je objecten aanmaakt dien je ze ook weer vrij te geven en te valideren of het object wel bestaat voordat je het aanspreekt. Zo werkt OOP eenmaal

Sorry maar dat is echt complete nonsens. Vrijgeven moet alleen als het taal en/of het object in kwestie dat vereist. In garbage collected talen is het bij veel objecten namelijk helemaal niet het geval dat je ze "vrij moet geven".

En kijken of objecten wel bestaan heeft compleet niets met OOP an sich te maken. Het hangt van de situatie af of een null reference überhaupt een valide program state is, en program state validation (typisch mbv asserts) is echt niet iets dat je bij uitstek terugvindt in OOP programmacode. Het is net zoiets als controleren of een bepaalde waarde niet negatief is. In het geval van een array size is het gegarandeerd dat het niet negatief is, dus ga je daar ook niet op controleren. Op dezelfde manier kan het ook gegarandeerd zijn dat een object gewoon bestaat, dan ga je ook niet alsnog zitten controleren of hij niet null is.

[ Voor 20% gewijzigd door .oisyn op 08-05-2013 17:15 ]

[.oisyn]

P.O. Box schreef op woensdag 08 mei 2013 @ 16:57:
[...]


volgens wordt hij wel uit een subklasse benaderd, dus is dat wel het antwoord m.i.:

$x wordt alléén benaderd vanuit set_x() en get_x(), en die zitten in de superklasse zelf. $x kan dus prima private zijn. En set_x() en get_x() zijn zelf public, dus die kunnen ook gewoon door subklasses worden aangeroepen. In de code die jij post wordt dodo() aangeroepen, die is public, dus geen probleem.

[ Voor 10% gewijzigd door .oisyn op 08-05-2013 17:12 ]

[BoringDay]

.oisyn schreef op woensdag 08 mei 2013 @ 16:58:
[...]

Sorry maar dat is echt complete nonsens. Vrijgeven moet alleen als het taal en/of het object in kwestie dat vereist. In garbage collected talen is het bij veel objecten namelijk helemaal niet het geval dat je ze "vrij moet geven".

En kijken of objecten wel bestaan heeft compleet niets met OOP an sich te maken. Het hangt van de situatie af of een null reference überhaupt een valide program state is, en program state validation (typisch mbv asserts) is echt niet iets dat je bij uitstek terugvindt in OOP programmacode. Het is net zoiets als controleren of een bepaalde waarde niet negatief is. In het geval van een array size is het gegarandeerd dat het niet negatief is, dus ga je daar ook niet op controleren. Op dezelfde manier kan het ook gegarandeerd zijn dat een object gewoon bestaat, dan ga je ook niet alsnog zitten controleren of hij niet null is.

Dus je laat het gewoon in het geheugen achter?
Lijkt me geen slimme zaak.
Volgens mij reserveert een object een deel van het geheugen welke je na het gebruik netjes vrijgeeft.

Je ziet veel applicaties dat niet altijd netjes doen het gevolg is memory leak.

[gertvdijk]

BoringDay schreef op donderdag 09 mei 2013 @ 00:14:
Dus je laat het gewoon in het geheugen achter?
Lijkt me geen slimme zaak.
Volgens mij reserveert een object een deel van het geheugen welke je na het gebruik netjes vrijgeeft.

Je ziet veel applicaties dat niet altijd netjes doen het gevolg is memory leak.

Je mist hier het punt dat .oisyn maakt: garbage collection. Je weet wel. Dat wat PHP, Python, Java, etc. zo "makkelijk" maakt t.o.v. native talen zoals C/C++.

[Caelorum]

Dat is het punt niet. Garbage collected talen hebben een garbage collector die het geheugen al dan niet voor je vrij maakt. Daar hoef jij verder niets aan te doen. Dat een taal OOP mogelijk maakt wil nog niet zeggen dat je meteen ook zelf geheugen moet managen. In het geval van C++ heb je (op wat classes uit std na) gelijk, maar bij bijv. C# moet je dat echt niet willen doen. Een deel van de kracht komt daar juist voort uit dat je het niet zelf doet. De garbage collector bepaalt of geheugen moet worden vrijgegeven. Dit is ook de reden waardoor sommige code sneller werkt in C# dan in C++, bijv. als je duizenden objecten aanmaakt en daarna verwijdert in korte tijd en weer aanmaakt. In C# kan de garbage collector besluiten het geheugen niet vrij te geven, maar te herbruiken, waar het in C++ wellicht (afhankelijk van de code) altijd wordt vrij gegeven.
Dat alles maakt nog niet dat C# OOP minder mogelijk maakt dan C++.

[ Voor 4% gewijzigd door Caelorum op 09-05-2013 00:24 ]