[PHP4] Probleem met scope / verwijzing / ?

[Gwaihir]

'k zit vast bij het coden en ik snap niet waarop precies. Hard op zoek naar hints dus..

De melding: Fatal error: Call to a member function on a non-object in 'regel twee hieronder'

PHP:

global $hic;
$hic->outputHandler->setView($this->view);

Bovenstaande staat in een class die daarmee graag wil doorgeven welke view hij wil gebruiken. $hic wordt wel als object herkend, maar $hic->outputHandler is volgens php geen object. Ik snap niet waarom niet, gezien wat daaraan vooraf gaat:

PHP:

class HIC
{
    //constructor
    function HIC()
    {
        $this->outputHandler = new HTMLOutputHandler;
    }
}
class HTMLOutputHandler
{
    function setView($view)
    {
        //bla bla
    }
}

$hic = new HIC;

[ Voor 13% gewijzigd door Gwaihir op 29-08-2005 16:52 ]

[Bosmonster]

Lijkt me dat je probleem ergens anders zit dan de code die je nu opgeeft, want die code klopt gewoon (dat tweede stuk dan).

Of je hebt ergens een references probleem misschien met $hic?

even testje met jouw code en werkt dus prima:

PHP:

error_reporting (E_ALL);

class HIC 
{ 
    //constructor 
    function HIC() 
    { 
        $this->outputHandler = new HTMLOutputHandler; 
    } 
} 
class HTMLOutputHandler 
{ 
    function setView($view) 
    { 
        echo $view;
    } 
} 


$hic = new HIC; 

function bla () {
    global $hic;
    $hic->outputHandler->setView('bla');
}

bla ();

[NMe]

Ik gok dat die class in een aparte file staat. Include je die wel voordat je $hic wil gebruiken?

[Gwaihir]

Bedankt voor die test Bosmonster, da's nog eens feedback

Ik heb de code nog een keer gevolgd -> niets gevonden. Ik heb dus maar alle voorkomens van 'hic' en 'outputHandler' doorgenomen. Maar helaas nog steeds niets fouts gevonden.

Bugje in PHP zelf (niet waarschijnlijk, maar toch maar effe uitsluiten)? Ik draai PHP Version 4.3.10-15, is jouwe wellicht nieuwer?

-NMe- schreef op maandag 29 augustus 2005 @ 17:05:
Ik gok dat die class in een aparte file staat. Include je die wel voordat je $hic wil gebruiken?

HIC en HTMLOutputHandler staan in dezelfde file. De functie bla (zoals Bosmonster 'm maar effe doopte) staat in een andere file. Deze file produceert de foutmelding -> dus ook "aanwezig". Bedankt voor de gok, maar helaas.

[ Voor 46% gewijzigd door Gwaihir op 29-08-2005 17:35 ]

[drm]

Kijk eens met var_dump of je uberhaupt wel te maken hebt met het object dat je verwacht. Ik vermoed namelijk dat je $hic ergens anders als een andersoortig object hebt geinitialiseerd of overschreven hebt. Iets als:

PHP:

class Spef {}

class HIC {
   function HIC () { $this->oh = new HtmlOh (); }
}
class HtmlOh () {
   function HtmlOh () { $this->someVar = "piet"; }
}

function funcA () {
   global $hic;
   echo $hic->oh->someVar; // echoes "piet"
}

function funcB () {
   global $hic;
   $hic = new Spef (); // oops! Hic is an object but doesn't contain an 'oh' member variable
}
$hic = new HIC ();
funcA ();
funcB ();
funcA (); // error

Met var_dump krijg je daar interessante informatie over te zien.

---

edit:

Je zou ook nog even na kunnen gaan of de constructor van HIC uberhaupt aangeroepen wordt. Misschien heb je de naam verkeerd gespeld? (Hoewel dat niet al te waarschijnlijk is met een drie-letterige classname, maar goed)

[ Voor 17% gewijzigd door drm op 29-08-2005 17:42 ]

[Gwaihir]

drm schreef op maandag 29 augustus 2005 @ 17:40:
Ik vermoed namelijk dat je $hic ergens anders als een andersoortig object hebt geinitialiseerd of overschreven hebt. Iets als:

PHP:

..
   $hic = new Spef (); // oops! Hic is an object but doesn't contain an 'oh' member variable
..
   $hic = new HIC ();
..

$hic komt (nog) maar 11x in de applicatie voor en die heb ik net een voor een achter elkaar afgelopen (leve de zoekfuncties ). Een tweede new was me daarbij zeker opgevallen.

Desondanks was de var_dump wel heel informatief: er is inderdaad een $hic aldaar, maar het bevat maar een deel van wat er in zou moeten zitten. De objecten toegevoegd via die constructor zijn er niet..

Je zou ook nog even na kunnen gaan of de constructor van HIC uberhaupt aangeroepen wordt.

Goed punt. Zojuist gecontroleerd: wordt aangeroepen.

[Bosmonster]

kun je iets meer posten van het stuk waar die foute $hic gemaakt wordt e.d.?

[Gwaihir]

Ik heb wat gevonden - en zoals meestal met de-buggen: een kleinigheidje over het hoofd gezien. Het was geen "include" die er nog niet was, maar wel net zoiets basics. "D'oh.." Kwam ongeveer hier op neer:

PHP:

class HIC  
{  
    //constructor  
    function HIC()  
    {  
           $this->controller = new Controller;           
           $this->outputHandler = new HTMLOutputHandler;  
    }  
}

En z'n constructor zet die controller gelijk aan het werk, waarbij hij uiteindelijk ook de outputHandler probeert aan te spreken. Dat gaat niet goed natuurlijk.

[ Voor 26% gewijzigd door Gwaihir op 29-08-2005 18:16 ]

[Gwaihir]

Helaas was omwisselen van die twee maar een deel van het probleem: ik lijk nog steeds twee verschillende "$hic" variabelen te hebben. D.w.z. wanneer ik het aan die constructor over laat, zoals hierboven, dan heeft de '$hic' die ik uiteindelijk aantref deze beide objecten niet. Wanneer ik ze elders toevoeg ($hic->outputHandler = new HTMLOutputHandler; en de ander), dan wel..

Iets meer posten.. ik weet zo effe niet wat.. die class HIC is in elk geval niet groter dan wat ik nu gepost heb.

[Bosmonster]

Tja.. kip/ei probleem Hij's nog bezig om dat object te instantieren. Beter is dus om dit soort dingen los te trekken ipv alles in de contructors proberen te proppen.

[Gwaihir]

Maar bij jou werkte het toch?

Het voordeel van dit in de constructor stoppen is dat ik op elke pagina van m'n applicatie een call uitspaar.

[Bosmonster]

Bij mij werkte het simpele voorbeeld boven

Wat doe je in die Controller constructor dan? global $hic? Mag hopen van niet?

Daar heb je parent toch voor?

(snap ff niet meer wat je probleem nu is.. )

[ Voor 26% gewijzigd door Bosmonster op 29-08-2005 18:38 ]

[Gwaihir]

Bosmonster schreef op maandag 29 augustus 2005 @ 18:36:
Bij mij werkte het simpele voorbeeld boven

Wat doe je in die Controller constructor dan? global $hic? Mag hopen van niet?

Eh... ja, global $hic ja.

Birdie begint het verschil tussen 't versimpelde voorbeeld en zijn code te zien en voelt nattigheid.

Hmm.. is er ook een post-constructor constructor aanroepbaar? D.w.z. een method die altijd wordt uitgevoerd, direct nadat de constructor helemaal klaar is met z'n werk?

Daar heb je parent toch voor?

parent werkt toch volgens de klassen-hiërarchie en bovendien statisch? Zou het erg tof vinden als er ook zo'n comando is dat naar de instance verwijst die een instance heeft gemaakt, maar ik heb het nog niet gevonden.

[ Voor 23% gewijzigd door Gwaihir op 29-08-2005 19:40 ]

[drm]

Birdie:
Eh... ja, global $hic ja.

Birdie begint het verschil tussen 't versimpelde voorbeeld en zijn code te zien en voelt nattigheid.

Je staat tot je lippen in het water

Hmm.. is er ook een post-constructor constructor aanroepbaar? D.w.z. een method die altijd wordt uitgevoerd, direct nadat de constructor helemaal klaar is met z'n werk?

Nee, want dat is wel ongeveer het belachelijkste wat ik ooit gehoord heb... Je kunt natuurlijk gewoon een methode aanroepen aan het eind van je constructor

PHP:

class A{
   function A () {
      $this->member1 = new Class1();
      $this->member2 = new Class2();
      $this->doSomethingWithMembers ();
   }

   function doSomethingWithMembers () {
      $this->member1->doSomething ();
      $this->member2->doSomethingElseWith ( $this->member2 );
   }
}

parent werkt toch volgens de klassen-hiërarchie

Klopt

en bovendien statisch?

Klopt niet. Een call naar een parent method via parent::parentMethod() werkt binnen de scope van het huidige object.

Zou het erg tof vinden als er ook zo'n comando is dat naar de instance verwijst die een instance heeft gemaakt, maar ik heb het nog niet gevonden.

Wat is er mis met een parameter, desnoods by reference?

PHP:

class A {
   function A () {
      $this->member = new B ( $this );
   }
}

class B {
   function B ( &$a ) {
      $this->aInstance =& $a;
   }
}

Maar het is op z'n zachts gezegd "bad practice" een class allerlei dingen op zijn parent object uit te laten voeren zo lang de parent nog bezig is met initialiseren. Je moet de constructor ook niet voor meer gebruiken dan initialisatie, dus het setten van members, creeeren van member objecten, dat soort dingen. het echte "aan het werk" gaan met 't object doe je met (andere) methoden.

Birdie:
Het voordeel van dit in de constructor stoppen is dat ik op elke pagina van m'n applicatie een call uitspaar.

Dit is wel zo ongeveer het slechtste argument voor bad design dat ik ooit gehoord heb

[Gwaihir]

drm schreef op maandag 29 augustus 2005 @ 19:52:
Je kunt natuurlijk gewoon een methode aanroepen aan het eind van je constructor

Nee helaas, in jouw voorbeeld ben je nog steeds aan het "doSomething-en" vanuit de constructor.

[...]
Klopt niet. Een call naar een parent method via parent::parentMethod() werkt binnen de scope van het huidige object.

Ah; goed om te weten.

[...]

[...]
Je staat tot je lippen in het water
[..]
Wat is er mis met [..]
Maar het is op z'n zachts gezegd [..]

Ehm.. zoals gezegd: ik voelde de nattigheid hoor. Geen al te erge rotdag gehad hoop ik?

Dit is wel zo ongeveer het slechtste argument voor bad design dat ik ooit gehoord heb

Eén van de redenen voor werken met OO: verminderen van code duplication.. Tevens worden objecten geacht een zekere mate van zelfvoorzienendheid / zelfstandigheid te hebben. Wanneer ze na hun constructie nog standaard met een init() aangeslingerd moeten worden vind ik dat dus minder elegant.

[ Voor 13% gewijzigd door Gwaihir op 29-08-2005 21:35 ]

[drm]

Birdie:
Nee helaas, in jouw voorbeeld ben je nog steeds aan het "doSomething-en" vanuit de constructor.

Mja, maar dat is ook alleen maar een probleem als je nog met die global wilt blijven werken. Dat moet je dus niet doen.

Ehm.. zoals gezegd: ik voelde de nattigheid hoor. Geen al te erge rotdag gehad hoop ik?

Nee hoor, mijn dag was niet al te best maar dat heeft er niet zo veel mee te maken. De nattigheid die jij voelde was dat het object tijdens het uitvoeren van de constructor nog niet toegekend was aan de global $hic. Dat is nattigheid. 't Feit dat je uberhaupt denkt een global te moeten gebruiken: dat is 't water tot aan je lippen. Merely a metaphore.

Eén van de redenen voor werken met OO: verminderen van code duplication..

"Een call uitsparen" is gewoon je reinste over-optimalisatie. Het is zinloos, geeft geen enkele tijdwinst en in de meeste gevallen word je code er alleen maar slechter van. Verder heb ik nog nooit van een term "code duplication" gehoord, maar het heeft vast iets met copy-pasten te maken, wat ik hier niet in herken.

Tevens worden objecten geacht een zekere mate van zelfvoorzienendheid / zelfstandigheid te hebben. Wanneer ze na hun constructie nog standaard met een init() aangeslingerd moeten worden vind ik dat dus minder elegant.

Nogmaals: het initialiseren van het object hoort dus in de constructor thuis. Als je dus al een method aan zou roepen van het object, zou dat geen init () zijn. Alle initialisatie hoort in de constructor thuis, en als er dingen zijn die niet in de constructor kunnen (bijvoorbeeld omdat je refereert aan een global die nog niet bestaat in jouw geval) is er iets goed mis met je ontwerp.

[Gwaihir]

drm schreef op maandag 29 augustus 2005 @ 22:05:
[...]
Mja, maar dat is ook alleen maar een probleem als je nog met die global wilt blijven werken. Dat moet je dus niet doen.

Globale variabelen bestaan ook met een reden hoor..

In mijn human interface component (bovenste laag van de app.) hangen een aantal objecten rond die samen een taak uitvoeren en daarvoor elkaar aanroepen. In Java zou je ze waarschijnlijk een namespace toebedelen, maar die heeft PHP niet dus heb ik er een global object $hic voor genomen. Dat 't een object is heeft wat (nadelige) gevolgen. Ik dacht er ook een voordeeltje uit te halen door de constructor zo te gebruiken, maar dat gaat dus helaas niet door - denkfoutje

N.B. met "init()" bedoelde ik niet de constructor, maar meer "de set van standaard te doorlopen handelingen".

Je heb nog nooit van het vermijden van meerdere malen dezelfde code in een applicatie gehoord? Hmm.. tja.. nou ja.. de voordelen daarvan zijn niet zo moeilijk voor te stellen: vermindering van werk, vergemakkelijken van onderhoud, etc. Een call verplaatsen van elke ingangspagina naar één centrale plek vind ik toch wel handig, hoor.

[whoami]

Birdie schreef op maandag 29 augustus 2005 @ 23:15:
[...]

Globale variabelen bestaan ook met een reden hoor..

Global variables are evil

[Gwaihir]

Als humor bedoeld, neem ik aan (al geeft die google helaas weinig gevatte teksten)? Anders is 't me toch echt te zwart-wit. Maar laten we die algemene discussie hier maar niet oprakelen.

Mocht iemand zich toch afvragen of er geen betere oplossing dan die global is, welkom natuurlijk, maar lees dan eerst even dit topic door voor de context: [rml][ PHP] Scope / namespace vraagstuk[/rml] (en misschien kun je dan het beste daar reageren).

[NMe]

Dat is niet als humor bedoeld. In 9 van de 10 gevallen (of eigenlijk 99 van de 100) is global vies. Het is onnodig, lelijk, en maakt je code moeilijk onderhoudbaar. Bijna altijd is er een betere oplossing te bedenken met parameteroverdracht tussen functies zelf.

[Gwaihir]

Daar ben ik me heel goed van bewust hoor. (Als hou het maar op ca. 9 van de 10 ).

Doch, is is altijd nog dat 10e geval - en dat bedoel ik met "bestaat met een reden"; anders kan het de taal net zo goed volledig uitgegooid worden. Als je het linkje volgt, dan zie je dat je zelf deze oplossing onderschreef..

Misschien kan het nog wel wat netter, al zie ik zo even niet hoe. Deze manier van werken levert me evenwel twee tot vier globals op, over een forse applicatie. Dat kan ik echt zo vreselijk vies niet vinden. Wat is het volgende advies? De $_REQUEST array ook maar gelijk over te nemen in een locale variabele en vervolgens te unsetten?

[ Voor 39% gewijzigd door Gwaihir op 30-08-2005 13:44 ]

[Janoz]

1 Java heeft geen namespaces
2 Iemand die zijn een stuk code volledig aan elkaar hangt met globale variabelen neem ik verminderd serieus wanneer deze met 'onderhoudbaarheid van het systeem' aan komt zetten.

Een belangrijk deel van het onderhoudbaar houden van code is het verkleinen van de scope. Op die manier is veel beter te zien wat er gebeurt en heb je bij aanpassing de minste kans dat er onvoorziene neveneffecten optreden.
Globale variabelen gebruiken druist hier linea recta tegenin.

---
Het kan ook gerust de taal uitgegooid worden. Hetzelfde geld voor de goto. Het probleem is dat het er ooit een keer ingezeten heeft en dat het bakcward compatibility breekt wanneer het eruit gehaald wordt. Noem mij die ene keer in de 10 dat het nodig is. Ik denk niet dat je een voorbeeld kunt verzinnen waarin het gebruik van globals noodzakelijk is en waarvoor niet een netere oplossing zonder globals te verzinnen is.

[ Voor 31% gewijzigd door Janoz op 30-08-2005 13:01 ]

[Gwaihir]

Tja, waar ik al bang voor was: dit wordt een oeverloze algemene discussie over de evil global

Laten we het s.v.p. wat concreter houden en dat andere draadje oppakken. Dat beschrijft het concrete probleem wat ik met deze incidentele global (max. één per applicatie laag) probeer op te lossen. Ik sta zeker open voor mooie alternatieven, maar voor zo'n algemeen "dat moet altijd beter kunnen" koop ik niets.

Heeft PHP dan (nog) een goto? Ik kan hem niet vinden.

[ Voor 9% gewijzigd door Gwaihir op 30-08-2005 13:09 ]

[whoami]

Tja, refactor je applicatie gewoon zodanig dat je die global niet meer nodig hebt.

[Sybr_E-N]

Birdie schreef op dinsdag 30 augustus 2005 @ 13:05:
Ik sta zeker open voor mooie alternatieven, maar voor zo'n algemeen "dat moet altijd beter kunnen" koop ik niets.

Waarom in PHP4, waarom stap je niet gelijk over naar PHP5. Daarin zijn de OOP mogelijkheden ietwat verbeterd iig. Om je OO code in PHP4 enigszins efficient te houden moet je al snel werken met references om copiën van huidige objecten tegen te gaan + bijbehoorde ongewenste neveneffecten. In PHP5 wordt dit juist weer automatisch voor je gedaan.

[Gwaihir]

En dat houdt in?

Neem (het meest richting "global" roepende voorbeeld) de probleem logica (PDC laag): volgens de OO gedachtengang zitten hier een aantal objecten in die "naar behoefte" met elkaar in contact kunnen treden. Welke public methods ze van elkaar gebruiken leg je "slechts" vast in je klasse documentatie.

Mijn oplossing daarom: instantieer de objecten die je op elk moment nodig hebt binnen een $pdc en laat ze dmv $pdc->objectInstance->method() met elkaar communiceren. Lijkt me dat $pdc om dat her en der mogelijk te maken een global moet zijn, of niet? Of is er een andere standaard oplossing voor dit probleem (in PHP)?

Ik weet ook wel dat globals - hoe zal ik het zeggen - niet het eerste zijn waar je naar grijpt, maar ik mis helaas de praktijkervaring met applicaties van dit formaat om te weten hoe het verder nog opgelost kan worden.

Edit: PHP5 staat bovenaan het verlanglijstje De server is nog niet zo ver en een paar oudere (stock) apps moeten nog nagelopen worden op PHP5 issues, maar 't duurt niet lang meer. PHP5 lost evenwel dit probleem niet op.

[ Voor 15% gewijzigd door Gwaihir op 30-08-2005 13:19 ]

[.oisyn]

Janoz schreef op dinsdag 30 augustus 2005 @ 12:59:
1 Java heeft geen namespaces

Als dat zo was was java wel erg onbruikbaar . Een namespace is niet meer dan het woord al zegt: een stukje ruimte waarin names (meestal identifiers of types) gedefinieerd zijn. Een package is een voorbeeld van een namespace dat tevens overeenkomt met het C++ en C# keyword namespace, maar een class is ook een namespace, en functies en zelfs compound statements in feite ook, hoewel je die laatste twee niet van buiten kunt accessen. Het is dan ook nauw verwant met scope, hoewel dat laatste meer is welke namespaces je op een bepaald moment kunt zien.

[drm]

Birdie:
Mijn oplossing daarom: instantieer de objecten die je op elk moment nodig hebt binnen een $pdc en laat ze dmv $pdc->objectInstance->method() met elkaar communiceren. Lijkt me dat $pdc om dat her en der mogelijk te maken een global moet zijn, of niet? Of is er een andere standaard oplossing voor dit probleem (in PHP)?

Heb je wel gelezen wat ik heb gezegd? het is basic OO om daarvoor een this-reference te gebruiken.

drm:
Wat is er mis met een parameter, desnoods by reference?

PHP:

class A {
   function A () {
      $this->member = new B ( $this );
   }
}

class B {
   function B ( &$a ) {
      $this->aInstance =& $a;
   }
}

Wat is daar niet duidelijk aan

[Janoz]

.oisyn schreef op dinsdag 30 augustus 2005 @ 13:31:
[...]

Als dat zo was was java wel erg onbruikbaar . Een namespace is niet meer dan het woord al zegt: een stukje ruimte waarin names (meestal identifiers of types) gedefinieerd zijn. Een package is een voorbeeld van een namespace dat tevens overeenkomt met het C++ en C# keyword namespace, maar een class is ook een namespace, en functies en zelfs compound statements in feite ook, hoewel je die laatste twee niet van buiten kunt accessen. Het is dan ook nauw verwant met scope, hoewel dat laatste meer is welke namespaces je op een bepaald moment kunt zien.

Daar heb je gelijk in, maar dat is volgens mij niet wat de topicstarter bij namespaces dacht .

[Gwaihir]

Gelezen: ja; als "basic" opgevat: nee nog niet; call me thick, of whatever, maar..

-> Ik kan niet bij naam ($hic) naar een klasse verwijzen voordat de constructor volledig doorlopen is (ok, makes sense). Maar ik kan wel een $this referentie naar die klasse maken voordat de constructor geheel doorlopen is? - Het werkt inderdaad maar het voelt toch vaag..

-> Als je op deze manier een aantal klassen koppelt levert dat een enorme recursieve janboel op. Heeft dat geen nare bijverschijnselen? var_dump krijgt van deze simpele voorbeeldconstructie al redelijk het heen en weer.. "Even" een var_dump van een werkelijk object doen voor wat debug info kan ik bij gebruik van zo'n constructie wel vergeten, of niet?

Janoz schreef op dinsdag 30 augustus 2005 @ 14:22:
[...]


Daar heb je gelijk in, maar dat is volgens mij niet wat de topicstarter bij namespaces dacht .

Ik bedoelde inderdaad "namespace" als taalconstructie / keyword. Ik ben thuis in Java noch C++ en onthoud daardoor kennelijk ook slecht bij welke ik, al voorbeelden doornemend, zo'n handigheid heb gezien. Sorry daarvoor.

[ Voor 26% gewijzigd door Gwaihir op 30-08-2005 14:37 ]

[.oisyn]

Birdie schreef op dinsdag 30 augustus 2005 @ 14:34:
-> Ik kan niet bij naam ($hic) naar een klasse verwijzen voordat de constructor volledig doorlopen is (ok, makes sense). Maar ik kan wel een $this referentie naar die klasse maken voordat de constructor geheel doorlopen is? - Het werkt inderdaad maar het voelt toch vaag..

Nee, dingen kunnen nu eenmaal niet tegelijk gedaan worden. Als jij dit doet:

PHP:

$a = func();

Kun je dan al bij $a in de functie func? Natuurlijk niet, het resultaat van func wordt pas aan $a toegekent als het resultaat ook daadwerkelijk bekend is, en dat is pas als de functie een waarde heeft gereturnd. Voor die tijd bestaat $a nog niet.

Hetzelfde geldt voor constructors, als jij $bla = new Bla() doet, dan wordt de constructor van Bla() aangeroepen op de members van dat object te initialiseren. Pas als het object geinitialiseerd is wordt hij toegekent aan $bla, niet eerder.

-> Als je op deze manier een aantal klassen koppelt levert dat een enorme recursieve janboel op. Heeft dat geen nare bijverschijnselen? var_dump krijgt van deze simpele voorbeeldconstructie al redelijk het heen en weer.. "Even" een var_dump van een werkelijk object doen voor wat debug info kan ik bij gebruik van zo'n constructie wel vergeten, of niet?

Ten eerste is var_dump een debugfeature en daar moet je je design niet op aanpassen. Ten tweede kan var_dump uiteraard gewoon overweg met circular references, anders krijg je binnen de kortste keren al een infinite loop.

[drm]

Birdie:
Gelezen: ja; als "basic" opgevat: nee nog niet; call me thick, of whatever, maar..

Ik noem je niet thick, ik heb alleen het idee dat je mijn tips negeert, en daar word ik een beetje simpel van.

-> Ik kan niet bij naam ($hic) naar een klasse verwijzen voordat de constructor volledig doorlopen is (ok, makes sense). Maar ik kan wel een $this referentie naar die klasse maken voordat de constructor geheel doorlopen is? - Het werkt inderdaad maar het voelt toch vaag..

Het is heel iets anders. $this is geen variabele die jij definieert, het is een standaard construct die een verwijzing naar de huidige object scope bevat. 't Kan best vaag voelen, maar het is een standaard constructie die in elke OO taal voorkomt.

-> Als je op deze manier een aantal klassen koppelt levert dat een enorme recursieve janboel op. Heeft dat geen nare bijverschijnselen? var_dump krijgt van deze simpele voorbeeldconstructie al redelijk het heen en weer.. "Even" een var_dump van een werkelijk object doen voor wat debug info kan ik bij gebruik van zo'n constructie wel vergeten, of niet?

Dat komt door het werken met references (die ampersand voor de parameter). var_dump heeft het daar moeilijk mee, inderdaad, maar dat is een mankement van PHP4, niet van de constructie op zich. References zijn altijd al een lastig verhaal geweest, maar je hebt references ook lang niet altijd nodig in PHP.

In dat opzicht is het kijken naar PHP5 overigens zeker de moeite waard, zeker nu je nog een hoop moet leren.

[Gwaihir]

.oisyn schreef op dinsdag 30 augustus 2005 @ 14:46:
[...]

Hetzelfde geldt voor constructors, als jij $bla = new Bla() doet, dan wordt de constructor van Bla() aangeroepen op de members van dat object te initialiseren. Pas als het object geinitialiseerd is wordt hij toegekent aan $bla, niet eerder.

Dat had ik begrepen. Wat mij verbaast is dat het object kennelijk al wel netjes aan "$this" is toegekend. Ik had verwacht dat die twee toekenningen min of meer gelijktijdig zouden gebeuren.

Ten eerste is var_dump een debugfeature en daar moet je je design niet op aanpassen. Ten tweede kan var_dump uiteraard gewoon overweg met circular references, anders krijg je binnen de kortste keren al een infinite loop.

Ja, hij geeft inderdaad na een paar loops "RECURSION" door. Ik bedoelde het ter illustratie: dat "ermee overweg kunnen" kost ongetwijfeld rekenkracht en die wil je bij het normaal lopen van de applicatie niet op zo'n manier verspillen. Vandaar mijn twijfel of dit echt de methode is. Aan de andere kant: als ik "bij normaal gebruik" in een situatie kom waarin die loop doorlopen wordt heb ik toch al iets fout gedaan.. dus als jullie dat zo zeggen..

Birdie baalt ervan dat hij als voorbeelden alleen maar matig geprogde PHP-apps en de relatief kleine voorbeeldjes uit boeken heeft

[ Voor 3% gewijzigd door Gwaihir op 30-08-2005 15:03 ]

[Gwaihir]

drm schreef op dinsdag 30 augustus 2005 @ 15:00:
[...]
Ik noem je niet thick, ik heb alleen het idee dat je mijn tips negeert, en daar word ik een beetje simpel van.

Ik had ze wel gelezen, maar ik had door de tekst die je er omheen schreef niet de indruk dat je dit als een (goede) oplossing zag. Daarnaast had ik net wat minder zin om uitgebreid en bedankend op je te reageren omdat je wat negatief overkwam door zoveel te benadrukken wat ik al gemerkt en bevestigd had dat fout was.

't Kan best vaag voelen, maar het is een standaard constructie die in elke OO taal voorkomt.

Okies

PHP is mijn eerste OO taal. Hiervoor zat ik nog aan de Turbo Pascal en AutoLISP (maar da's al weer effe terug). In PHP en OO ben ik (helaas) volledig zelfonderwijzend, waardoor ik nooit in de keuken van een project met deze behoeftes (kwa grondig design) heb kunnen kijken. Mijn insteek kan daardoor soms best wat knullig overkomen; dat krijg je met boekenwijsheid, hè

In dat opzicht is het kijken naar PHP5 overigens zeker de moeite waard, zeker nu je nog een hoop moet leren.

Die luxe zal ik weldra hebben (zie boven)

[Bosmonster]

Birdie schreef op dinsdag 30 augustus 2005 @ 15:01:
[...]

Dat had ik begrepen. Wat mij verbaast is dat het object kennelijk al wel netjes aan "$this" is toegekend. Ik had verwacht dat die twee toekenningen min of meer gelijktijdig zouden gebeuren.

Daar is toch niks geks aan? Je moet je object intern toch al wel aan kunnen spreken, zelfs in je constructor.

[Gwaihir]

Eh, ja goed punt..

Birdie is blij dat het Bosmonster bomen door 't bos kan zien