[PHP] Herhaalde uitvoering, require vs. require_once

[SvMp]

Samengevat is mijn vraag als volgt: Wat is beter bij herhaalde uitvoering: Meerdere malen dezelfde include (require) of gebruik van require_once icm. een functie-aanroep.


Om de boel wat overzichtelijk te houden, werk ik met include-bestanden die acties uitvoeren.
Welke acties is afhankelijk van de variabele $actie. De variabele $actie en/of $status wordt gewijzigd afhankelijk van de uit te voeren acties. Vervolgens eindigt de lus of wordt er opnieuw een actie uitgevoerd.

Vereenvoudigd fragment:

code:

$status=0;
while ($status==0) {
   if (($actie==1) || ($actie==2)) require 'actieA.php';
   elseif (($actie>=10000) && ($actie<10100)) require 'actieB.php';
   else require 'actieC.php';
}

Zoals je ziet is er sprake van een lus. Als $status 0 blijft, dan wordt opnieuw een actie uitgevoerd. Het is dus mogelijk dat hetzelfde bestand meer dan één keer wordt geinclude.

Het include bestand voert acties uit en kan probleemloos vaker worden aangeroepen. Zoals hierboven beschreven werkt het prima.

Toch vraag ik mij af of het niet beter kan. Ik heb geen goed gevoel bij het herhaaldelijk includen, ik vind het niet zuiver.

Een alternatief is ipv. require require_one gebruiken icm. met een functie.

code:

...
   if (($actie==1) || ($actie==2)) { require_once 'actieA.php'; actieA(); }
...

inhoud actieA.php:

code:

<?php
   function actieA() {
      global $actie, $status;
 // van alles doen
   }
?>

Nadeel van deze methode is dat het iets omslachtiger is.

Wat is efficiënter/sneller/beter?

[Koetjeboe]

Wat is er tegen ze allebei gewoon altijd includen?

[Creepy]

Je misbruikt include nu als functie aanroep. Include de juiste scripts helemaal bovenaan je eigen script en roep dan vervolgens op de plekken waar je de functionaliteit nodig hebt de betreffende functies aan. Waarom ben je zo dynamisch aan het includen? De overhead van een include is echt minimaal en zou ik me absoluut geen zorgen over maken.

[Laurens-R]

Een include wordt toch ook gedurende compiletime uitgevoerd (en dan bedoel ik in het geval van php; de interne vertaling naar bytecode)? Dus gewoon bovenaan je script doen; het verschil merk je toch niet gedurende uitvoer. Het is namelijk een directive die voor de compilatie van je daadwerkelijke code wordt uitgevoerd en kan je dus ook niet conditional includen via een normaal if statement... tenzij je zoals in C++ gebruik kan maken van macro's. En ook dan gebeuren dit soort acties voor de daadwerkelijke vertaling naar naar bytecode.

Misschien zit ik er naast hoor (zoveel verstand heb ik ook weer niet over de interne werking van de PHP interpreter), maar het lijkt me nogal logisch vanuit een compiler/interpreter perspectief, omdat je anders de kans loopt dat niet alle symbols in kaart zijn gebracht voordat alles naar bytecode vertaald wordt.

edit: op W3Schools wordt beschreven dat include's / requires worden uitgevoerd voordat het script gestart word: http://www.w3schools.com/PHP/php_includes.asp

Daarnaast is deze aanpak verre van duidelijk en totaal tegen alle gewoontes in en je wint er qua performance niets bij. Het enige wat je momenteel doet is de onduidelijkheid in je code vergroten.

m.a.w. Gewoon includen aan de top van je php bestand.

[ Voor 58% gewijzigd door Laurens-R op 24-10-2009 14:19 ]

[djexplo]

EvilB2k schreef op zaterdag 24 oktober 2009 @ 13:54:
...
m.a.w. Gewoon includen aan de top van je php bestand.

100% mee eens

[Dwightjo]

EvilB2k schreef op zaterdag 24 oktober 2009 @ 13:54:

edit: op W3Schools wordt beschreven dat include's / requires worden uitgevoerd voordat het script gestart word: http://www.w3schools.com/PHP/php_includes.asp

Dit is niet geheel correct.
In het geval van include.

PHP:

<?php

$waarde = 2;

if( $waarde <= 1)
{
    include 'includefile1.php';
}
else
{
    echo 'include file is niet geladen';
}
?>

includefile1.php zal in dit geval niet door de parser heen gehaald worden.
Wanneer je echter het "include" commando vervangt door "require" dan is dit wel het geval.

Maar ben het met de overige posters eens dat je het liever boven aan je script kunt includen.
Overhead is minimaal.

[Voutloos]

Dwightjo schreef op zaterdag 24 oktober 2009 @ 16:51:
includefile1.php zal in dit geval niet door de parser heen gehaald worden.
Wanneer je echter het "include" commando vervangt door "require" dan is dit wel het geval.

Onzin, het enige verschil tussen include en require is dat require een fatal error geeft bij fouten.

O, en ook maar mijn bevestiging: function calls (of OO) zijn hiervoor bedoeld. Puur het includen van wat imperative code is onduidelijk, onoverzichtelijk en zorgt gegarandeerd voor extra bugs omdat je continu in dezelfde scope aan het roeren bent.

EvilB2k schreef op zaterdag 24 oktober 2009 @ 13:54:
Een include wordt toch ook gedurende compiletime uitgevoerd
...
Misschien zit ik er naast hoor

Je zit ernaast. Niet alles moet per se in 1x van tevoren geparset worden en conditioneel includen kan dus wel.

[ Voor 44% gewijzigd door Voutloos op 24-10-2009 17:19 ]

[Cartman!]

Functie van maken dus

[SvMp]

Duidelijke meningen

Alles dus includen. De reden dat ik het dynamisch doe, is inderdaad performance. Ik ging er namelijk van uit dat die includes niet worden geladen tenzij de uitkomst van het if-statement daar aanleiding toe geeft. Ik verwacht dat ze site namelijk zal groeien tot zo'n 20 includes, en een aantal daarvan is behoorlijk groot. In de meeste gevallen is er echter slechts ééntje echt nodig. Dus ik wil inderdaad voorkomen dat PHP de niet gebruikte includes gaat verwerken.

[ID-College]

Ik zou gewoon een functie maken die je kan aanroepen en die de juiste file terugstuurt die jij weer kan includeren. Maar blijkbaar is dit nogal verschillend

[SvMp]

Nog een paar opmerkingen:

- Dat het bugs veroorzaakt valt volgens mij wel mee, omdat ik dat includen slechts op één plek doe. Het is dus niet een grote brei spaghetti.

- Nog een ander probleem, gezien de kritische opmerkingen over het on-the-fly gebruiken van includes in PHP:
De site wordt meertalig. Elke include met acties begint met een reeks strings in het Engels, zoals $tekst1="Search location", $tekst2="Select region", etc..
Een vertaling herdefinieert dezelfde strings, maar dan in een andere taal. Die staan in een include.
Reden om het zo te doen is dat ik zo talen deels kan ondersteunen. Zo kan ik meest belangrijke stukken alvast vertelen naar een of andere taal. Gettext gebruiken vind ik veel te omslachtig en geeft volgens mij veel overhead.
Maar nadeel van mijn methode is het dynamisch gebruiken van die includes dat in dit topic sterk wordt afgeraden.
Ik kan ook doen:

code:

if ($taal==100) { // Nederlands
   $tekst1='Zoek plaats';
   $tekst2='Selecteer regio';
} elseif ($taal==200) { // Duits 
...

Maar dan krijg ik allemaal if-statements en rijen strings, terrwijl een gebruiker slechts één taal gebruikt.
Natuurlijk kan ik ook al die strings in een tabel zetten, kleine moeite, ik heb toch al een database, maar dat geeft volgens mij ook veel overhead. En dan denk ik: Zo gek is het idee van die includes toch niet?

- Ik denk trouwens dat het niet waar is dat includes direct in het begin worden geladen. Volgens mij pas als het script bij het include (of require) commando is aangekomen én het uitvoert. Reden dat ik dat denk: Je kunt bij include en require ook variabelen gebruiken, en de waarde daarvan is vooraf niet bekend.

[ Voor 10% gewijzigd door SvMp op 24-10-2009 22:35 ]

[Voutloos]

SvMp schreef op zaterdag 24 oktober 2009 @ 22:28:
- Dat het bugs veroorzaakt valt volgens mij wel mee, omdat ik dat includen slechts op één plek doe. Het is dus niet een grote brei spaghetti.

Ok, maar voor elke vertaalstring een variabele in je globale scope definieren vervuilt ook wel een beetje.

- Ik denk trouwens dat het niet waar is dat includes direct in het begin worden geladen.

Dat zei ik toch al.

Vertalingen netjes doen is altijd toch wel een pittige opgave, want elke manier heeft wel z'n nadelen. En gettext blijft ook zuigen zolang het niet thread safe is.

[SvMp]

@Voutloos: Over vertalen zijn een aantal goede topics te vinden op GoT, en geen enkele oplossing is in alle opzichten perfect. In die zin wil ik het includen wat ik voor die vertalingen doe - wat geen schoonheidsprijs verdient - relativeren.

[Leftblank]

SvMp schreef op zaterdag 24 oktober 2009 @ 22:28:
- Nog een ander probleem, gezien de kritische opmerkingen over het on-the-fly gebruiken van includes in PHP:
De site wordt meertalig. Elke include met acties begint met een reeks strings in het Engels, zoals $tekst1="Search location", $tekst2="Select region", etc..
Een vertaling herdefinieert dezelfde strings, maar dan in een andere taal. Die staan in een include.
Reden om het zo te doen is dat ik zo talen deels kan ondersteunen. Zo kan ik meest belangrijke stukken alvast vertelen naar een of andere taal. Gettext gebruiken vind ik veel te omslachtig en geeft volgens mij veel overhead.
[..]

Includes kunnen in het geval van multilanguage dingen wel handig zijn natuurlijk; je zou kunnen proberen de taal van je user te laden (/languages/<taal>.php oid) en anders terug te vallen naar een default file. Verder zou ik dat dan wel aanpakken dmv. een array met beschrijvende indices, eventueel zelfs per losse view, ipv allerlei losse strings.

Het voordeel daarvan is m.i. dat je het geheel achter één variabele hebt in plaats van een hele lading losse, met minder kans om allerlei meuk onbedoeld te overschrijven, wat wel prettig is wanneer je een uitbreiding maakt na een lange tijd niks gedaan te hebben

[ Voor 18% gewijzigd door Leftblank op 25-10-2009 13:18 . Reden: Quote ingekort ]