Keskustelu: Nettisivujen teko: php: require/include funktiossa

Terve,

Tuli tuossa lähinnä mieleen, ei tullut vielä suorituksessa vastaan - toivottavasti ei tulekkaan.

Miten muistinhallinnan yms. kannalta tuo require-mahtaa käyttäytyä?
jos mulla on lyhyt fuktion tyyliin:

function nimi() {
   require("funk.php");
   return haenimi(1234);
}

Nyt kun tätä funktiota kutsutaan vaikka 1 000 000 kertaa luupissa, niin miten tuo require mahtaa käyttäytyä, jos siinä on vaikka 100 funktiota ja 10000 riviä koodia eli aika iso. Ilmeisesti tuo fyysinen tiedosto on kuitenkin välimuistissa, josta se luetaan. Tuleekos tästä jokin ongelma vai hoituuko se ilman ongelmia?

Mielummin sivun alkuu ja vielä require_once(), jolloin tiedosto sisällytetään vain kerran. Lisäämisen jälkeen funktioiden pitäisi olla näkyvyysalueella kyseisessä tiedostossa.

<?php
function A(){
  return 3;
}

function AB(){
  return A();
}

echo AB();
// 3
?>

Yep noin se yleensä on tullut tehtyä.

Kokeilin tuota require_oncea samassa funktiossa ja käyttäytyi siten, että eka toimii ja on käytettävissä, mutta toisella kerralla ei tunnista funktiot ollenkaan. Require toimii ok.

Älä laita sitä funktioon, vaan sivun alkuun. Sisällytys pitää tehdä siis vain kerran sivun alussa, jonka jälkeen funktiot ovat käytettävissä.

<?php
require_once("func.php");

while(true){
    echo A();
}
?>

tiedosto1.php:

<?php
require_once( "funk.php" );
function nimi() {
   return haenimi(1234);
}

Jos funk.php pitää sisällään oikeasti funktioita - eikä vain nimi-funktion runkoa käärittynä "funktioksi", ne kannattaa tietysti liittää muualle kuin funktion sisään kuten yllä. Jos haenimi on täsmälleen sama funktio kuin nimi, kannattaa haenimi-funktion runko pistää suoraan nimi-funktioon eikä turhaan tupla-kääriä sitä.
Eli näin, tiedosto1.php:

<?php
function nimi() {
   # tähän se, mitä haenimi pitää sisällään ilman funktio-kääreitä :-)
}

Kummalla tahansa tavalla nimi-funktiota käytetään näin, tiedosto 2:

<?php
require_once( "tiedosto1.php" );
$nimi = nimi();

Kiitti! Nuo on ihan selvät.

Tätä samaa vielä miettien:
*Mitenkä tämmöinen on hoideltu esim. jaettavissa moduleissa. Sielläkin taitaa olla jonkin verran includeja?

Aivan kuten yllä, oliko tässä sinusta jotain ihmeellistä?

Yleispätevänä sääntönä voi sanoa, että funktio on väärä paikka include-riveille. Säännöstä saa poiketa vasta, kun keksii jonkin syyn, jonka muutkin tunnustavat todelliseksi. Itse en ole vielä tarpeeksi hyvään syyhyn törmännyt.

>Aivan kuten yllä, oliko tässä sinusta jotain ihmeellistä?
Eipä siinä.

>Yleispätevänä sääntönä voi sanoa, että funktio on väärä paikka
>include-riveille.
Se on ihan hyvä sääntö.

Tämmöinen tuli vielä mieleeni samasta asiasta:

Jos funktiossa käytetään vaikka "joitakin ohjelman alustusmuuttujia". Ne ovat erillisessä tiedostossa vaikka pelkkinä sijoituslauseina, niin eikös ainakin nimikonfliktien vuoksi ne olisi hyvä tehdä vain funktion sisäisiksi muuttujiksi juuri includella vaikka sotii sääntöä vastaan?

Oikea-Tapa™ on käyttää jotain asetusformaattia, kuten ini, yaml, jne. (ja luokkia). Konflikteja kannattaa ennaltaehkäistä ehdottomasti jo suunnitteluvaiheessa.

Keksitkö jonkin esimerkin, jossa olisi kaksi samannimistä asiaa? Yleensä aloittelijoiden "nimikonfliktit" johtuvat huonosta nimeämisestä. Jos muuttujan tai funktion nimi kertoo oikeasti, mihin sitä käytetään, konflikteja ei lähes koskaan tule. Kärjistetty esimerkki: $nimi ja $nimi versus $etunimi ja $sukunimi.

ootte ihan oikeassa. Tämä nyt lähinnä tietämättömän pohdintaa. Tuo include funktiossa vaan selventäisi koodia.

Kerran oon törmännyt samannimiseen.
Edellä oli määritelty taulukko, muistaakseni kayttajatunnus ja myöhemmin koodissa viitattiin eri tarkoituksessa ja kappas input-kentässä luki yllättäen array.

Käyttäjätunnustaulukon ei varmasti pitäisi olla globaali eikä myöskään samalla näkyvyysalueella minkään tulostamiseen liittyvän kanssa. (Tai jos kyseessä on sivulle tulostettava tieto, miksi nimi on $kayttajatunnus eikä esimerkiksi $kirjautuneet_kayttajat tai muuta kuvaavampaa?) Kyseessä on siis tyypillinen amatöörimainen suunnitteluvirhe.