[PHP] - method uit ander child van parentclass aanroepen

[xilent_xage]

Hoi,

Ik zit me even heel erg te schamen omdat ik niet weet hoe ik dit kan doen:

PHP:

class hi {

    protected $a;
    protected $b;

    function __construct() {
        $this->a = new foo();
        $this->b = new bar();
    }

}

class Foo extends hi {

    public function test() {
        echo "hello tweakers";
    }

}

class Bar extends hi{

    public function wees_beleefd() {
        parent::a->test();
    }

}

new hi(); //geeft error

Ook als ik a en b public of zelfs public static maak werkt het niet. Wat doe ik verkeerd / hoe moet het wel?

[ Voor 4% gewijzigd door xilent_xage op 15-07-2010 16:55 . Reden: Onhandige classnames :) ]

[Morax]

"parent" is een gereserveerd keyword om te verwijzen naar de klasse die ge-overerft wordt (En je klasse Bar extend geen klasse). Ofwel: andere naam voor de klasse "Parent" verzinnen

[ Voor 11% gewijzigd door Morax op 15-07-2010 16:49 ]

[steffex]

http://php.net/manual/en/keyword.extends.php

[xilent_xage]

Jullie zijn snel, sneller dan ik mijn lapje testcode kon verbeteren . Ik had idd verkeerde classname gekozen en extends vergeten. Ik heb de code inmiddels gefixt zoals ik het bedoelde. Het werkt dus niet. Wie o wie?

Parse error: syntax error, unexpected T_OBJECT_OPERATOR...

[ Voor 12% gewijzigd door xilent_xage op 15-07-2010 16:59 ]

[Laurens-R]

Wat heb je al gedaan om achter het probleem te komen? Wat zijn je eerste bevindingen?

edit: gaat dit trouwens niet eeuwig door? Je maakt namelijk nieuwe instances aan van Foo en Bar (let op de caps btw) in de constructor van hi. Maar omdat deze twee inheriten van hi, wordt er dus weer een een nieuwe instance van Foo en Bar gemaakt bij het aanroepen van de base class constructor... en dat gaat zo maar door.

Maar nu heb ik dus te weinig verstand van PHP om zeker te weten dat de constructor van de base class ook aangeroepen wordt bij het creeeren van een nieuwe instance van een inherited class.

[ Voor 75% gewijzigd door Laurens-R op 15-07-2010 17:07 ]

[Helmet]

Normaal neemt het object de variabelen van de parent over, binnen de class hi zou in principe dus de variabele a beschikbaar moeten zijn. Volgens mij is het echter niet mogelijk om een extend van de class in de parent op te nemen (in mijn php geeft dit een memory leak) het is echter wel mogelijk om objecten op te nemen in de parent en deze zullen in de extended-variant gewoon beschikbaar zijn ik heb je voorbeeld iets aangepast.

PHP:

class hi {

    protected $a;
    protected $b;

    function __construct() {
        $this->a = new foo();
        $this->b = new bar2();
    }

}

class Foo  {

    public function test() {
        echo "hello tweakers";
    }

}

class Bar2 {
    public function __construct()
    {
        echo "woohoo";
    }
}

class Bar extends hi{

    public function wees_beleefd() {
       echo $this->a->test();
    }

}

$t = new bar(); //geeft error
$t->wees_beleefd();

Als je de inhoud van het t (bar) object dumpt krijg je ook netjes de objecten te zien:

code:

sobject(Bar)#1 (2) {
  ["a":protected]=>
  object(Foo)#2 (0) {
  }
  ["b":protected]=>
  object(Bar2)#3 (0) {
  }
}

Wat is de reden om een childobject in de parent op te slaan daar de methoden toch al beschikbaar zijn op het moment dat je de extended versie aanmaakt?

[ Voor 9% gewijzigd door Helmet op 15-07-2010 17:09 ]

[xilent_xage]

EvilB2k schreef op donderdag 15 juli 2010 @ 17:02:
Wat heb je al gedaan om achter het probleem te komen? Wat zijn je eerste bevindingen?

Nouja ik snap OOP best redelijk, dus de manual van php helpt niet echt verder. Ik snap hoe classes, methods en properties werken, en wat private/public/protected en static zijn en hoe extends werkt. Veel verder dan dat gaat de manual niet. Googlen heeft niet zoveel zin omdat je met de bekende keywords (zie titel) een paar miljoen hits hebt met simpele problemen.

Dus even een testscriptje (bovenstaand) in mekaar geflansd, en daarmee zitten spelen. Bijv de variabelen public maken of public static. En de functies in de children public maken, dat soort testjes.

Ik vermoed dat

• OF dit niet kan en ik een verkeerde structuur gebruik omdat dan blijkbaar niemand anders zoiets doet
• OF ik iets heel simpels verkeerd doe / niet weet

Voorlopig zet ik mn geld op het laatste

[ Voor 11% gewijzigd door xilent_xage op 15-07-2010 17:09 ]

[Pin0]

zit je op deze manier niet in een eeuwige lus?

new hi() ->roept de __construct method aan. In die construct method doe je een new foo() welke extend op hi en dus ook de construct van hi aanroept die weer een new foo aanmaakt etc...

Ik denk dat een factory design patern iets voor jou is! (hoewel ik dit niet 100% kan verantwoorden waarom ik dat denk :-)

[xilent_xage]

@eeuwige lus-problemen: Nee. Bij het aanroepen van een child roept php NIET de init van de parent aan.

[Sebazzz]

xilent_xage schreef op donderdag 15 juli 2010 @ 17:10:
@eeuwige lus-problemen: Nee. Bij het aanroepen van een child roept php NIET de init van de parent aan.

Natuurlijk wel. In bijna iedere object georienteerde taal roept de child constructor altijd de constructor van de parent aan. Zou een beetje aparte designkeuze zijn als het niet zo zou zijn.

edit: Het is dus niet zo. Beetje raar, omdat je met half geconstructe object kan zitten dan.

[ Voor 10% gewijzigd door Sebazzz op 15-07-2010 17:14 ]

[Helmet]

xilent_xage schreef op donderdag 15 juli 2010 @ 17:10:
@eeuwige lus-problemen: Nee. Bij het aanroepen van een child roept php NIET de init van de parent aan.

Volgens mij wel hoor, tenzij deze in het child element opnieuw gedefinieerd wordt zie dit voorbeeld

PHP:

class a {
    function __construct()
    {
        echo "a";
    }
}

class b extends a {
    function test() {}
}

$b = new  b();

Geeft als uitvoer: a

Terwijl als je de functie override in de extended-class

PHP:

class b extends a {

    function __construct()
    {
        echo "b";
    }

    function test() {}
}

$b = new  b();

Je als uitvoer: b krijgt

Het door jouw geschetste voorbeeld geeft dus wel degelijk een oneindige loop

[ Voor 23% gewijzigd door Helmet op 15-07-2010 17:16 ]

[Sebazzz]

Volgens de manual niet:

quote: http://www.php.net/manual/en/language.oop5.decon.php

Note: Parent constructors are not called implicitly if the child class defines a constructor. In order to run a parent constructor, a call to parent::__construct() within the child constructor is required.

[Helmet]

Dat is toch ook precies wat ik zeg? als de child-class een constructor heeft dan wordt de constructor van de parent genegeerd maar in het door de TS geschetste voorbeeld hebben beide child-classes geen constructor en daarom zal zijn code in een oneindige lus terecht komen (totdat er geen objecten in het geheugen meer aangemaakt kunnen worden)

[Janoz]

Sebazzz schreef op donderdag 15 juli 2010 @ 17:13:
[...]

Natuurlijk wel. In bijna iedere object georienteerde taal roept de child constructor altijd de constructor van de parent aan. Zou een beetje aparte designkeuze zijn als het niet zo zou zijn.

edit: Het is dus niet zo. Beetje raar, omdat je met half geconstructe object kan zitten dan.

Precies. In een fatsoenlijke OO taal wel, maar dit geeft destemeer de brakheid van de OO implementatie van PHP aan.

@Topicstarter:
Wat is uberhaupt de reden waarom je Foo en Bar wilt laten extenden van Hi? Ik denk namelijk dat je wat dingen door elkaar haalt. Kort door de bocht heb je in een OO ontwerp 2 relaties. De 'is een' en de 'heeft een'. Wat jij hier gemaakt hebt heeft allebij. De Foo is een Hi, maar Hi heeft ook een Foo. Dat klopt natuurlijk niet helemaal.

[gertjuhh]

Sebazzz schreef op donderdag 15 juli 2010 @ 17:15:
Volgens de manual niet:

[...]

Note: Parent constructors are not called implicitly if the child class defines a constructor. In order to run a parent constructor, a call to parent::__construct() within the child constructor is required.

Dat is hier niet aan de orde.
Indien de child geen __construct method heeft word netjes de parent::__construct aangeroepen.

Edit: ik was weer eens te traag...

[ Voor 3% gewijzigd door gertjuhh op 15-07-2010 17:21 ]

[Sebazzz]

Helmet schreef op donderdag 15 juli 2010 @ 17:18:
Dat is toch ook precies wat ik zeg?

Er stond eerst 'a' in je post volgens mij

[Janoz]

Op zich is dat nog maar net hoe je dat leest. Er staat dat de parent constructor niet impliciet aangeroepen wordt wanneer je een child constructor implementeert. Nergens wordt gezegd dat de constructor wel impliciet wordt aangeroepen wanneer je geen child constructor definieerd.

De uitleg is op zijn minst dubieus en iig ambigu.

[xilent_xage]

Ok, die loop lag dus aan de brakheid van mijn voorbeeld, in mijn werkelijke code heeft elke class zn eigen constructor. Anyway , ik begin inmiddels gezien de vele opmerkingen te geloven dat het toch een kwestie is van een verkeerde OO-structuur.

Ik zal even toelichten wat ik probeer te bereiken:

• Mijn index.php doet niks anders dan een config file inlezen en op basis van de instellingen een bepaalde versie van mijn framework aanroepen.
• Mijn framework bestaat uit een soort backbone die inkomende requests afhandelt.
• Deze backbone begint met het aanroepen van een aantal objecten die overal in de code gebruikt moeten kunnen worden: Een urlparser, de output-handler, de debugger/profiler, de sql-connectie enz.
• Al deze objecten zijn netjes OO gebouwd, dus als class met properties en methods.
• De objecten hebben mekaar nodig, zo geeft de sql-connectie bij elke query netjes een debuglog aan de debugger/profiler. En de urlparser moet bij de database kunnen.

Bovenstaande opzet leek me hiervoor geschikt, maar blijkbaar kan dat niet, of moet ik een andere opzet kiezen. Hoe zouden jullie dit doen?

Tot op heden gebruikte ik daarvoor steeds global, maar het lijkt me dat dat met een iets meer OO-benadering beter moet kunnen?

[ Voor 5% gewijzigd door xilent_xage op 15-07-2010 17:37 ]

[Sebazzz]

Janoz schreef op donderdag 15 juli 2010 @ 17:23:
De uitleg is op zijn minst dubieus en iig ambigu.

De documentatie laat wel wat ruimte over voor interpretatie ja, en schendt minstens één van de zeven regels over documenteren: Formuleer positieve zinnen.

[.oisyn]

Janoz schreef op donderdag 15 juli 2010 @ 17:23:
Op zich is dat nog maar net hoe je dat leest. Er staat dat de parent constructor niet impliciet aangeroepen wordt wanneer je een child constructor implementeert. Nergens wordt gezegd dat de constructor wel impliciet wordt aangeroepen wanneer je geen child constructor definieerd.

De uitleg is op zijn minst dubieus en iig ambigu.

Maar de specs zijn niet belangrijk. Belangrijk is hoe het in PHP is geïmplementeerd. En het is nou eenmaal zo dat ze op een nieuw geconstruct object de __construct method aanroepen, indien die bestaat. Als die dan is geoverride in een derived class dan wordt die dus aangeroepen, en niet die van de base. Dat is dus gewoon logisch, en geen bug ofzo.

[Sebazzz]

Maar de specs zijn niet belangrijk. Belangrijk is hoe het in PHP is geïmplementeerd.

Je mag hopen dat de implementatie is gedaan volgens de specs. Dan heb je dit probleem niet.

[Verwijderd]

Volgens mij is het al opgelost maar parent::a->test(); moet met variable teken dus:
parent::$a->test();

[Shagura]

xilent_xage schreef op donderdag 15 juli 2010 @ 17:29:
Ok, die loop lag dus aan de brakheid van mijn voorbeeld, in mijn werkelijke code heeft elke class zn eigen constructor. Anyway , ik begin inmiddels gezien de vele opmerkingen te geloven dat het toch een kwestie is van een verkeerde OO-structuur.

Ik zal even toelichten wat ik probeer te bereiken:

• Mijn index.php doet niks anders dan een config file inlezen en op basis van de instellingen een bepaalde versie van mijn framework aanroepen.
• Mijn framework bestaat uit een soort backbone die inkomende requests afhandelt.
• Deze backbone begint met het aanroepen van een aantal objecten die overal in de code gebruikt moeten kunnen worden: Een urlparser, de output-handler, de debugger/profiler, de sql-connectie enz.
• Al deze objecten zijn netjes OO gebouwd, dus als class met properties en methods.
• De objecten hebben mekaar nodig, zo geeft de sql-connectie bij elke query netjes een debuglog aan de debugger/profiler. En de urlparser moet bij de database kunnen.

Bovenstaande opzet leek me hiervoor geschikt, maar blijkbaar kan dat niet, of moet ik een andere opzet kiezen. Hoe zouden jullie dit doen?

Tot op heden gebruikte ik daarvoor steeds global, maar het lijkt me dat dat met een iets meer OO-benadering beter moet kunnen?

Klinkt goed. Het is natuurlijk wel zo dat de afhankelijkheden allemaal 'heeft een' relaties zijn en geen 'is een' (wat je een beetje leek te doen in de topicstart).

De sql-connectie heeft dus een logger nodig en is dit natuurlijk niet. De database en logger hebben dan ook geen overeenkomstig gedrag. Deze relaties los je over het algemeen op met dependency injection, klinkt fancy maar dit kan bijvoorbeeld makkelijk door de dependency mee te geven aan de klasse die hem nodig heeft in de constructor:

PHP:

class Backbone {
    protected $logger, $database;

    public function __construct() {
        $this->logger = new Logger();
        $this->database = new Database($this->logger);
    }
}

class Database {
    protected $logger;

    public function __construct(Logger $logger) {
        $this->logger = $logger;
    }

   public function query() {
       // query stuff here
       $this->logger->log($debugInfo);
   }
}

Zoiets dus. Zo kun je overal de dependencies doorgeven waar ze nodig zijn.

Het is wel zo dat je al snel sommige objectpointers door je hele applicatie door aan het geven bent (met name loggers en databases ) en dat kan al snel voelen alsof je veel te veel loze code hebt die niks anders doet dan objecten doorschuiven. Je kan dit eventueel oplossen door van deze objecten singletons te maken, wat ook nog enigszins verdedigbaar is voor database en (zeker) logging objecten. Ik zelf gebruik echter nooit singletons omdat ze net als global variables een global state in je programma introduceren waardoor afhankelijkheden tussen klassen al snel onduidelijk worden en de afhankelijkheden ook minder dynamisch te veranderen zijn (zie ook: http://www.c2.com/cgi/wiki?GlobalVariablesAreBad).

Er zijn ook wel andere mogelijkheden zoals extra abstractielagen toevoegen, maar dit maakt het geheel al snel veel te abstract en omslachtig voor wat je waarschijnlijk in eerste instantie nodig hebt

Zoiets wat je bedoelde?

offtopic:
Wat een geblaat altijd over PHP en hoe slecht het wel niet is, maar het heeft naar mijn mening een van de duidelijkste manuals. Die zin vind ik ook totaal niet dubbelzinnig aangezien het verwachte gedrag wel heel erg wordt geïnsinueerd. Om het dan gelijk ambigu te noemen...

[ Voor 4% gewijzigd door Shagura op 15-07-2010 19:11 ]

[Lye]

xilent_xage schreef op donderdag 15 juli 2010 @ 16:45:
Hoi,

Ik zit me even heel erg te schamen omdat ik niet weet hoe ik dit kan doen:

PHP:

class hi {

    protected $a;
    protected $b;

    function __construct() {
        $this->a = new foo();
        $this->b = new bar();
    }

}

class Foo extends hi {

    public function test() {
        echo "hello tweakers";
    }

}

class Bar extends hi{

    public function wees_beleefd() {
        parent::a->test();
    }

}

new hi(); //geeft error

Ook als ik a en b public of zelfs public static maak werkt het niet. Wat doe ik verkeerd / hoe moet het wel?

De parent class heeft geen constante of methode genaamd a, alleen een property. Probeer het eens aan te roepen met:

PHP:

parent::$a->test();

Overigens wordt de dubbele punt gebruikt in statische situaties, kun je niet gewoon $this->a->test() aanroepen?

[.oisyn]

Sebazzz schreef op donderdag 15 juli 2010 @ 18:27:
[...]
Je mag hopen dat de implementatie is gedaan volgens de specs. Dan heb je dit probleem niet.

En daarom hebben andere talen dat probleem dan ook niet (je snapte hopelijk dat ik sarcastisch was?)

Shagura schreef op donderdag 15 juli 2010 @ 18:54:
Wat een geblaat altijd over PHP en hoe slecht het wel niet is, maar het heeft naar mijn mening een van de duidelijkste manuals. Die zin vind ik ook totaal niet dubbelzinnig aangezien het verwachte gedrag wel heel erg wordt geïnsinueerd. Om het dan gelijk ambigu te noemen...

Het is per definitie ambigu, want het is om meerdere manieren te interpreteren. Insinuaties en verwachtingen doen daar geheel niets aan af.

En als je PHP een van de duidelijkste manuals vind hebben dan heb je gewoon niet genoeg ervaring met manuals. Veel bij-effecten en specifiek gedrag moet je maar uit de comments destilleren, die de helft van de tijd ook nog eens gewoon niet kloppen. De warning die je bij http://php.net/foreach kunt lezen over dat een reference blijft wijzen naar het laatste element stond daar bijvoorbeeld eerst niet. Toen werd er een bugreport gedaan, dat werd afgewezen aangezien "het nou eenmaal zo geïmplementeerd is", vervolgens plaatste iemand een comment erover onder de pagina, en pas veel later werd het daadwerkelijk aan de documentatie toegevoegd. Als je van tevoren een goede spec schrijft en daar vervolgens tegenaan programmeert dan zijn er, anders dan bugs, ook geen rare bijwerkingen en kun je de documentatie altijd in 1 keer compleet opstellen.

[Sebazzz]

.oisyn schreef op vrijdag 16 juli 2010 @ 12:09:
[...]

En daarom hebben andere talen dat probleem dan ook niet (je snapte hopelijk dat ik sarcastisch was?)

Eigenlijk niet, sarcasme-meter was kapot

Als je van tevoren een goede spec schrijft en daar vervolgens tegenaan programmeert dan zijn er, anders dan bugs, ook geen rare bijwerkingen en kun je de documentatie altijd in 1 keer compleet opstellen.

Wat ik wel interessant vind, weet je dat ze het op die manier gedaan hebben of denk je dat?

[.oisyn]

Dat blijkt uit hoe de Zend mensen reageren op dergelijke bugreports. Dat is altijd "dat is geen bug, zo hebben we het geïmplementeerd". Tja, volgens die redenatie kun je ook nooit een bug hebben. In geen enkel geval hoor je iets als "dat hebben we zo bedacht om argument X" of "wat jij voorstelt is niet handig wegens Y". Dat impliceert dat ze gewoon maar beginnen met typen, en niet echt over dingen nadenken. En al helemaal niet openstaan voor suggesties.

Voorbeeld.

[ Voor 10% gewijzigd door .oisyn op 16-07-2010 15:47 ]

[afraca]

.oisyn schreef op vrijdag 16 juli 2010 @ 12:09:

En als je PHP een van de duidelijkste manuals vind hebben dan heb je gewoon niet genoeg ervaring met manuals. Veel bij-effecten en specifiek gedrag moet je maar uit de comments destilleren, die de helft van de tijd ook nog eens gewoon niet kloppen. De warning die je bij http://php.net/foreach kunt lezen over dat een reference blijft wijzen naar het laatste element stond daar bijvoorbeeld eerst niet. Toen werd er een bugreport gedaan, dat werd afgewezen aangezien "het nou eenmaal zo geïmplementeerd is", vervolgens plaatste iemand een comment erover onder de pagina, en pas veel later werd het daadwerkelijk aan de documentatie toegevoegd. Als je van tevoren een goede spec schrijft en daar vervolgens tegenaan programmeert dan zijn er, anders dan bugs, ook geen rare bijwerkingen en kun je de documentatie altijd in 1 keer compleet opstellen.

offtopic:
Ik begrijp heel goed wat je bedoelt, maar ook zeker wat Shagura bedoelt. Wat betreft de overzichtelijkheid/mooiheid (ja, bewust een debiel woord gekozen) doet PHP het mijn inziens echt heel goed, ik kan heel snel en duidelijk zien wat voor typen ik terugkrijg van een functie, wat ik erin behoor te stoppen en dergelijke. Tja, dat gaat nou niet bijzonder diep, en gaan we inderdaad kijken naar de documentatie van language constructs of ingebouwde classes dan wordt het zeker geen pretje. Juist omdat ik slechts hobby-matig mij bezig houd met PHP en Python denk ik dat ik een goed zicht heb op de "toegankelijkheid" van zo'n manual. Maar ook ik loop nu tegen problemen aan naarmate ik mij meer en meer met OOP ga bezig houden, of zoals een eerder topic van mij al aankaartte, met een ingebouwde class als RecursiveDirectoryIterator...