PHP en scopes: wat is good practice?

[Snake]

Modbreak:

Afgesplitst van [PHP] $_POST meegeven in include();.

Tarabass schreef op maandag 28 juli 2008 @ 13:26:
Je kan dan toch gewoon in je include het volgende zetten?

PHP:

if isset($_POST['variable']) {
    $variable = $_POST['variable'];
}

_ZO_ ranzing.

In PHP werkt dit, maar in een andere taal bestaat $variable alleen tussen uw { }, dit is dus echt bad practice.

Wil je het toch doen, doe het dan zo:

PHP:

$var = null;

if(isset($_POST['var']))
{
    $var = $_POST['var'];
}

[ Voor 7% gewijzigd door NMe op 29-07-2008 02:58 ]

[posttoast]

Snake schreef op maandag 28 juli 2008 @ 13:51:
[...]

_ZO_ ranzing.

In PHP werkt dit, maar in een andere taal bestaat $variable alleen tussen uw { }, dit is dus echt bad practice.

Wil je het toch doen, doe het dan zo:

PHP:

$var = null;

if(isset($_POST['var']))
{
    $var = $_POST['var'];
}

Hoe zou jij het doen dan (ervan uitgaande dat je de tweede manier ook niet je van het vindt)?

[Patriot]

Snake schreef op maandag 28 juli 2008 @ 13:51:
[...]

_ZO_ ranzing.

In PHP werkt dit, maar in een andere taal bestaat $variable alleen tussen uw { }, dit is dus echt bad practice.

Wil je het toch doen, doe het dan zo:

PHP:

$var = null;

if(isset($_POST['var']))
{
    $var = $_POST['var'];
}

Je overdrijft enorm. Ook al moet je in andere talen dergelijke variabelen wel vooraf declareren, dat is in PHP gewoon niet nodig. Het is algemeen aanvaardbaar als je dat niet doet, het hoeft gewoon niet in PHP.

[disjfa]

Patriot schreef op maandag 28 juli 2008 @ 13:58:
[...]
Je overdrijft enorm. Ook al moet je in andere talen dergelijke variabelen wel vooraf declareren, dat is in PHP gewoon niet nodig. Het is algemeen aanvaardbaar als je dat niet doet, het hoeft gewoon niet in PHP.

Dat iets niet hoeft betekend niet dat je ineens ranzig mag gaan programeren Als het netjes kan is het beter gewoon netjes op te schrijven. En dat maakt code overzichtelijker

[Cartman!]

Ik declareer ook niet al mn variabelen in mn controllers, wel in mn models/services voor documentatie. Waarom zou je trouwens $_POST['var'] perse willen omzetten naar $var, je hebt de variabele al maar geeft em alleen een andere naam... gebruik dan gewoon lekker $_POST['var'] in je script verder, dan is het tenminste ook nog duidelijk dat het een postvar is.

[Verwijderd]

Snake schreef op maandag 28 juli 2008 @ 13:51:
In PHP werkt dit, maar in een andere taal bestaat $variable alleen tussen uw { }, dit is dus echt bad practice.

Is dat serieus waar? Dat zou betekenen dat je elke var uit elke willekeurige functie kunt benaderen en dat lijkt me heel erg stug.

[.oisyn]

Hij bedoelt het juist andersom . Een variabele aangemaakt binnen een compound statement zal niet buiten dat compound statement bestaan. Ik ken echter geen talen waarbij je variabelen niet van tevoren hoeft te definieren die dat doen - alleen op functie-niveau.

Verwijderd schreef op maandag 28 juli 2008 @ 13:38:
ah kijk :-) Daar zat inderdaad het probleem in! Thanks guys!..
Ik heb overigens die include dit weekend nog verbouwd naar http://etc. omdat ik dan ook dingen als informatie.php?aktie=bekijken zou kunnen includen..
Zouden get-variabelen dan ook meegestuurd moeten kunnen worden op deze manier?

Niet op de manier waarbij je letterlijk ?actie=bekijken gebruikt bij het includen, maar je kan natuurlijk ook gewoon de $_GET array wijzigen voor je die file include. Echter, het is dan imho netter om een functie te maken die doet wat die include doet, en in die include die eigenlijk ook een opzichzelfstaande pagina is ook die functie aanroepen.

[ Voor 58% gewijzigd door .oisyn op 28-07-2008 14:26 ]

[Snake]

Verwijderd schreef op maandag 28 juli 2008 @ 14:21:
[...]
Is dat serieus waar? Dat zou betekenen dat je elke var uit elke willekeurige functie kunt benaderen en dat lijkt me heel erg stug.

Niet in functies, maar in dit soort if's en dergelijke wel.

Patriot schreef op maandag 28 juli 2008 @ 13:58:
[...]


Je overdrijft enorm. Ook al moet je in andere talen dergelijke variabelen wel vooraf declareren, dat is in PHP gewoon niet nodig. Het is algemeen aanvaardbaar als je dat niet doet, het hoeft gewoon niet in PHP.

In een simpel scriptje is dat geen probleem, maar daarna verlies je al lang de overzichtbaarheid.

posttoast schreef op maandag 28 juli 2008 @ 13:53:
[...]

Hoe zou jij het doen dan (ervan uitgaande dat je de tweede manier ook niet je van het vindt)?

Wat vind je slecht aan mijn manier?

Eventueel kan dit:

PHP:

$var = (isset($_POST['var'])) ? $_POST['var'] : null;

Maar dat is gewoon anders geschreven.

Een variable moet je _ALTIJD_ initialiseren, dat is good practice, en dan kom je al heel wat minder voor verassingen te staan

[Tarabass]

Snake schreef op maandag 28 juli 2008 @ 13:51:
Wil je het toch doen, doe het dan zo:

PHP:

$var = null;

if(isset($_POST['var']))
{
    $var = $_POST['var'];
}

Die twee haakjes was inderdaad een typo en horen er netjes omheen. Voor de rest neem ik iemand die professioneel met twee FF'en schrijft niet geheel serieus

[Snake]

Tarabass schreef op maandag 28 juli 2008 @ 14:32:
[...]

Die twee haakjes was inderdaad een typo en horen er netjes omheen. Voor de rest neem ik iemand die professioneel met twee FF'en schrijft niet geheel serieus

Ik doelde ook totaal niet op die haakjes, ik doelde op het niet hebben van de declaratie van $variable voor uw 'if' statement.

[posttoast]

Snake schreef op maandag 28 juli 2008 @ 14:26:


Wat vind je slecht aan mijn manier?

Eventueel kan dit:

PHP:

$var = (isset($_POST['var'])) ? $_POST['var'] : null;

Maar dat is gewoon anders geschreven.

Een variable moet je _ALTIJD_ initialiseren, dat is good practice, en dan kom je al heel wat minder voor verassingen te staan

Ik vind er niets slechts aan, maar je zei zelf "Wil je het toch doen, doe het dan zo:". Daarmee leek je te suggeren dat deze manier ook niet goed was, en dat snapte ik niet. Snap je?

[Snake]

posttoast schreef op maandag 28 juli 2008 @ 14:36:
[...]


Ik vind er niets slechts aan, maar je zei zelf "Wil je het toch doen, doe het dan zo:". Daarmee leek je te suggeren dat deze manier ook niet goed was, en dat snapte ik niet. Snap je?

Ah neen dat was slecht verwoord

Ik vind PHP op dit gebied een beetje te vergevingsgezind, en PHP wordt ook vaak gezien als entypoint voor door te stappen naar een 'echte' programmeertaal, maar dit soort fouten zorgt ervoor dat de gebruikers een foute manier van doen meekrijgen.

Maar deze discussie is echt al zo vaak gevoerd hoor

[Patriot]

disjfa schreef op maandag 28 juli 2008 @ 14:00:
[...]

Dat iets niet hoeft betekend niet dat je ineens ranzig mag gaan programeren Als het netjes kan is het beter gewoon netjes op te schrijven. En dat maakt code overzichtelijker

Het slaat echt nergens op om het ranzig te noemen. Het is gewoon absoluut niet nodig in PHP, en het is daarom niet ranzig alleen maar omdat het in andere programmeertalen moet. Het maakt de code mijns inziens ook totaal niet overzichtelijker.

[posttoast]

Mjah, ik heb de errorreporting op mijn ontwikkelserver op E_ALL staan, dus ik moet sowieso alle vars declareren. Anders word ik gek van de foutmeldingen.

[disjfa]

Patriot schreef op maandag 28 juli 2008 @ 14:40:
[...]
Het slaat echt nergens op om het ranzig te noemen. Het is gewoon absoluut niet nodig in PHP, en het is daarom niet ranzig alleen maar omdat het in andere programmeertalen moet. Het maakt de code mijns inziens ook totaal niet overzichtelijker.

Bedenk zo. Leer programeren en tik code in of speel met scripttalen.

Geen probleem wat je doet, er zijn alleen mensen die het liever netjes opgeschreven zien

[Tarabass]

Snake schreef op maandag 28 juli 2008 @ 14:35:
[...]

Ik doelde ook totaal niet op die haakjes, ik doelde op het niet hebben van de declaratie van $variable voor uw 'if' statement.

LOL!! Je hebt je onderschrift veranderd

[Tarabass]

Patriot schreef op maandag 28 juli 2008 @ 14:40:
[...]


Het slaat echt nergens op om het ranzig te noemen. Het is gewoon absoluut niet nodig in PHP, en het is daarom niet ranzig alleen maar omdat het in andere programmeertalen moet. Het maakt de code mijns inziens ook totaal niet overzichtelijker.

Ik schrijf dan ook het liefst zo weinig mogelijk code. Variabelen declareren doe ik pas in classes, vind het in een simpel include totaal overbodig. Als het werkt, werkt het. En het liefst met zo weinig mogelijk regels

[Patriot]

posttoast schreef op maandag 28 juli 2008 @ 14:43:
Mjah, ik heb de errorreporting op mijn ontwikkelserver op E_ALL staan, dus ik moet sowieso alle vars declareren. Anders word ik gek van de foutmeldingen.

Dan doe je toch echt iets verkeerd. Zelfs op E_STRICT geeft dit geen problemen:

PHP:

if (isset($_POST['var'])) {
  $var = $_POST['var'];
}

Je moet er inderdaad geen dingen op uitvoeren, maar dat is gewoon een ander verhaal. Het slaat nergens op om in PHP van te voren al je variabelen te declareren die je verder in het script gaat gebruiken (en dan heb ik het even over non-OO). Om het vervolgens met een null waarde te declareren is helemaal onnodig, omdat een variabele die null is door PHP beschouwd word als zijnde niet gedeclareerd (althans, voor functies als isset, je krijgt geloof ik geen notice).

PHP is gewoon een taal die inderdaad vergevingsgezind is, maar daar is het voor gemaakt. Het is mijns inziens gewoon vreemd om te stellen dat code die gewoon prima is niet klopt omdat het niet voldoet aan strictere eisen van een andere programmeertaal.

EDIT: Als ik het heb over prima code, dan heb ik het over code die op (minstens) E_ALL geen notices/warnings etc. geeft.

[ Voor 5% gewijzigd door Patriot op 28-07-2008 14:53 ]

[disjfa]

Patriot schreef op maandag 28 juli 2008 @ 14:52:
[...]

PHP:

if (isset($_POST['var'])) {
  $var = $_POST['var'];
}

PHP:

if (isset($_POST['var'])) {
  $var = $_POST['var'];
}
echo $var;

^^ zo werkt het alleen ineens niet meer in strict modus.

[posttoast]

Patriot schreef op maandag 28 juli 2008 @ 14:52:
[...]


Dan doe je toch echt iets verkeerd. Zelfs op E_STRICT geeft dit geen problemen:

PHP:

if (isset($_POST['var'])) {
  $var = $_POST['var'];
}

Je moet er inderdaad geen dingen op uitvoeren, maar dat is gewoon een ander verhaal. Het slaat nergens op om in PHP van te voren al je variabelen te declareren die je verder in het script gaat gebruiken (en dan heb ik het even over non-OO). Om het vervolgens met een null waarde te declareren is helemaal onnodig, omdat een variabele die null is door PHP beschouwd word als zijnde niet gedeclareerd (althans, voor functies als isset, je krijgt geloof ik geen notice).

PHP is gewoon een taal die inderdaad vergevingsgezind is, maar daar is het voor gemaakt. Het is mijns inziens gewoon vreemd om te stellen dat code die gewoon prima is niet klopt omdat het niet voldoet aan strictere eisen van een andere programmeertaal.

Het stuk code dat jij geeft, geeft geen error. Maar dit wel als $_POST['var'] als er geen $_POST is toch?:

PHP:

if (isset($_POST['var'])) {
  $var = $_POST['var'];
}

echo $var;

edit: wat disjfa zegt dus.

[Patriot]

disjfa schreef op maandag 28 juli 2008 @ 14:53:
[...]

PHP:

if (isset($_POST['var'])) {
  $var = $_POST['var'];
}
echo $var;

^^ zo werkt het alleen ineens niet meer in strict modus.

Nee, zo ook niet:

PHP:

<?php
adsfkl;af
?>

Gek hè? We hebben het over het wel of niet van te voren declareren van variabelen. Dat er vervolgens manieren zijn om door te scripten waarop het script wel fouten geeft staat daar gewoon buiten.

[Tarabass]

disjfa schreef op maandag 28 juli 2008 @ 14:53:
[...]

PHP:

if (isset($_POST['var'])) {
  $var = $_POST['var'];
}
echo $var;

^^ zo werkt het alleen ineens niet meer in strict modus.

Maar zo wel?

PHP:

if (isset($_POST['var'])) {
  $var = $_POST['var'];
  echo $var;
}

[posttoast]

Patriot schreef op maandag 28 juli 2008 @ 14:57:
[...]


Nee, zo ook niet:

PHP:

<?php
adsfkl;af
?>

Gek hè? We hebben het over het wel of niet van te voren declareren van variabelen. Dat er vervolgens manieren zijn om door te scripten waarop het script wel fouten geeft staat daar gewoon buiten.

Ja, hallo Piet. Ik ga er vanuit dat je een variabele declareert om er later nog iets mee te doen. En dat kan dus mis gaan als je niet zorgt dat hij sowieso gedeclareerd is, of je nou een $_POST hebt of niet.

[.oisyn]

posttoast schreef op maandag 28 juli 2008 @ 14:55:
Het stuk code dat jij geeft, geeft geen error. Maar dit wel als $_POST['var'] als er geen $_POST is toch?:

En dat moet je dan dus ook niet doen als je $var niet eerst hebt geïnitialiseerd.

Het is imho onzin om te zeggen dat het een netter is. Maar de semantiek verandert wel - in het ene geval bestaat er altijd een $var (als dat is wat je wilt, dan moet je dat ook zo doen), in het andere geval is $var meer equivalent aan de staat van $_POST["var"]. Het ligt aan jouw specifieke use-case wat het netst is.

posttoast schreef op maandag 28 juli 2008 @ 14:58:
[...]

Ja, hallo Piet. Ik ga er vanuit dat je een variabele declareert om er later nog iets mee te doen.

Hoi Kees, je definieert in het ene geval dus alleen de variabele als $_POST["var"] gezet is. In dat geval moet je er dus ook alleen wat mee doen als $_POST["var"] (of $var zelf natuurlijk) gezet is. Je kan niet de semantiek van de ene situatie proberen toe te passen op de andere om aan te tonen dat die andere situatie niet goed zou zijn . Die aanname van jou klopt dus al niet om mee te beginnen.

[ Voor 37% gewijzigd door .oisyn op 28-07-2008 15:04 ]

[Cartman!]

posttoast schreef op maandag 28 juli 2008 @ 14:55:
Het stuk code dat jij geeft, geeft geen error. Maar dit wel als $_POST['var'] als er geen $_POST is toch?:

PHP:

if (isset($_POST['var'])) {
  $var = $_POST['var'];
}

echo $var;

edit: wat disjfa zegt dus.

Waarom zou je dat doen Als je net besloten hebt dat je die variabele niet hebt, waarom ga je verderop dan toch iets ermee doen? Dan zit je logica gewoon niet goed in elkaar imo.

PHP:

if (isset($_POST['var'])) {
  $var = $_POST['var'];

// doe iets met die postvar
}

// hier die je andere dingen, maar niet die postvar gebruiken, die heb je niet

[disjfa]

Cartman! schreef op maandag 28 juli 2008 @ 15:10:
[...]
Waarom zou je dat doen Als je net besloten hebt dat je die variabele niet hebt, waarom ga je verderop dan toch iets ermee doen? Dan zit je logica gewoon niet goed in elkaar imo.

Omdat over het algemeen je wat sneller wat meer met je variabelen gaat doen. Als je een variabele hebt en er weinig mee zou doen is dat perfect. Maar zodra je twee variabelen hebt gaat het al moeilijker worden.

Dus van te voren definieren en lekker mee werken zodat je het later makkelijk kan aanpassen/toevoegen is niet te veel gevraagd

[Patriot]

posttoast schreef op maandag 28 juli 2008 @ 14:58:
[...]

Ja, hallo Piet. Ik ga er vanuit dat je een variabele definiëert om er later nog iets mee te doen. En dat kan dus mis gaan als je niet zorgt dat hij sowieso definiëert is, of je nou een $_POST hebt of niet.

Mijn punt is, dat ik die code alleen zou gebruiken als ik weet dat het later geen problemen geeft. Als ik weet dat ik later de waarde gewoon ga printen dan maak ik er bijvoorbeeld zoiets van:

PHP:

<?php

$var = (isset($_POST['var'])) ? $_POST['var'] : '';

?>

Het is m.i. gewoon niet netter om van te voren al je variabelen te gaan definiëren. Ik kan me best voorstellen dat het voor iemand die veel met andere programmeertalen werkt iets makkelijker is, maar dat is imho gewoon gewenning.

[ Voor 2% gewijzigd door Patriot op 28-07-2008 15:19 . Reden: ja meester :+ ]

[.oisyn]

DEFINIEREN!!!
Jullie met jullie gedeclareer . In PHP kun je niets expliciet declareren.

Declareren: "er bestaat een ..."
Definieren: "hier is een ..."

[ Voor 53% gewijzigd door .oisyn op 28-07-2008 15:19 ]

[Cartman!]

disjfa schreef op maandag 28 juli 2008 @ 15:15:
[...]

Omdat over het algemeen je wat sneller wat meer met je variabelen gaat doen. Als je een variabele hebt en er weinig mee zou doen is dat perfect. Maar zodra je twee variabelen hebt gaat het al moeilijker worden.

Dus van te voren definieren en lekker mee werken zodat je het later makkelijk kan aanpassen/toevoegen is niet te veel gevraagd

Dat vind ik juist in tegendeel. Als ik ergens iets wil doen, al is het met meerdere vars tegelijk, dan check ik liever op dat punt of het voldoet aan de voorwaarden dan dat ik het gewoon gebruik en het leeg, danwel NULL, blijkt te zijn.

btw, 'Omdat over het algemeen je wat sneller wat meer met je variabelen gaat doen' ? Hoe bedoel je dit

edit: kan dit niet beter afgesplitst worden?

[ Voor 9% gewijzigd door Cartman! op 28-07-2008 15:26 ]

[Tarabass]

disjfa schreef op maandag 28 juli 2008 @ 15:15:
[...]

Omdat over het algemeen je wat sneller wat meer met je variabelen gaat doen. Als je een variabele hebt en er weinig mee zou doen is dat perfect. Maar zodra je twee variabelen hebt gaat het al moeilijker worden.

Dus van te voren definieren en lekker mee werken zodat je het later makkelijk kan aanpassen/toevoegen is niet te veel gevraagd

Stel je voor dat je een lege variabele wilt echoën ofzo, dan moet je dat natuurlijk wel kunnen doen

[NMe]

Cartman! schreef op maandag 28 juli 2008 @ 15:10:
Waarom zou je dat doen Als je net besloten hebt dat je die variabele niet hebt, waarom ga je verderop dan toch iets ermee doen? Dan zit je logica gewoon niet goed in elkaar imo.

Het hangt, zoals .oisyn al zegt, af van wat je wil doen. Ik heb vaak een constructie als deze:

PHP:

$var = "";
if (isset($_POST["var"])) {
  $var = $_POST["var"];
}

// snip

echo $var; //in de templatecode

Vooral bij het weergeven van optionele invoergegevens is iets dergelijks handig. Wanneer je je variabele alleen binnen de scope van je if nodig hebt, is er natuurlijk niks mis met wat er in de eerste instantie gepost werd.

[Whazor]

-NMe- schreef op dinsdag 29 juli 2008 @ 03:01:
[...]

Het hangt, zoals .oisyn al zegt, af van wat je wil doen. Ik heb vaak een constructie als deze:

PHP:

$var = "";
if (isset($_POST["var"])) {
  $var = $_POST["var"];
}

// snip

echo $var; //in de templatecode

Vooral bij het weergeven van optionele invoergegevens is iets dergelijks handig. Wanneer je je variabele alleen binnen de scope van je if nodig hebt, is er natuurlijk niks mis met wat er in de eerste instantie gepost werd.

Dan moet je array_key_exists gebruiken want isset kijkt alleen of $_POST bestaat en niet of "var" bestaat.

[Patriot]

Whazor schreef op dinsdag 29 juli 2008 @ 03:19:
[...]


Dan moet je array_key_exists gebruiken want isset kijkt alleen of $_POST bestaat en niet of "var" bestaat.

Pertinent onwaar.

EDIT: Misschien is het ook handig als Snake even aangeeft wat hij precies bedoelt. Een lijst met variabelen aan het begin van de global scope die ergens verderop in het script gebruikt gaan worden, of het definiëren vlak voor de variabele nodig is.

[ Voor 34% gewijzigd door Patriot op 29-07-2008 04:16 ]

[NMe]

Whazor schreef op dinsdag 29 juli 2008 @ 03:19:
[...]

Dan moet je array_key_exists gebruiken want isset kijkt alleen of $_POST bestaat en niet of "var" bestaat.

Misschien moet je dit soort opmerkingen niet maken als je niet eerst getest hebt of het echt zo is.

Patriot schreef op dinsdag 29 juli 2008 @ 04:01:
[...]

EDIT: Misschien is het ook handig als Snake even aangeeft wat hij precies bedoelt. Een lijst met variabelen aan het begin van de global scope die ergens verderop in het script gebruikt gaan worden, of het definiëren vlak voor de variabele nodig is.

Dat maakt voor onze verdere discussie toch niet uit?

[Whazor]

-NMe- schreef op dinsdag 29 juli 2008 @ 14:20:
[...]

Misschien moet je dit soort opmerkingen niet maken als je niet eerst getest hebt of het echt zo is.

Dit is wel zo want $_POST is een array en ISSET is voor variabelen. En als je array_key_exists doet kijk je of de key bestaat in de array.

En bij php strict geeft isset fouten en array_key_exists niet.

[disjfa]

Whazor schreef op dinsdag 29 juli 2008 @ 14:45:
[...]
Dit is wel zo want $_POST is een array en ISSET is voor variabelen. En als je array_key_exists doet kijk je of de key bestaat in de array.

En bij php strict geeft isset fouten en array_key_exists niet.

Er word al door minimaal 3 man beweerd dat jij een keertje je eigen bevindingen moet nakijken. Gaat er dan geen belletje rinkelen je checkt niet of je post bestaan, maar of een variabele in je post bestaat. Dat zijn 2 verschillende dingen die je nu over het hoofd ziet.

isset werkt gewoon.

[.oisyn]

Whazor schreef op dinsdag 29 juli 2008 @ 14:45:
[...]


Dit is wel zo want $_POST is een array en ISSET is voor variabelen. En als je array_key_exists doet kijk je of de key bestaat in de array.

En bij php strict geeft isset fouten en array_key_exists niet.

(zucht)

PHP:

$aap[1] = 2;
var_dump(isset($aap[0]));
var_dump(isset($aap[1]));
var_dump(isset($noot[0]));

Goh, wat gek, PHP zegt { false, true, false } ipv { true, true, false }. Dan moet dat wel een bug in PHP zijn, want wat Whazor zegt klopt immers altijd .

En de documentatie van isset zelf bugt dan natuurlijk ook, want die zegt:

PHP:

$a = array ('test' => 1, 'hello' => NULL);

var_dump(isset($a['test']));            // TRUE
var_dump(isset($a['foo']));             // FALSE
var_dump(isset($a['hello']));           // FALSE

Het verschil tussen isset() en array_key_exists() is trouwens dat die eerste ook false geeft als een variabele null is (en dus wel gezet is), en dat de tweede een notice geeft als de gerefereerde variabele geen array of object is (en dus ook als die niet bestaat). Oftewel, met isset() kun je in een keer kijken of heel $bla[1][2]["aap"]["noot"] geldig is.

En deze opmerking:

Dit is wel zo want $_POST is een array en ISSET is voor variabelen

slaat natuurlijk ook nergens op. Alsof $_POST geen variabele is . En op een bepaalde manier is $aap[3] óók een variabele, eentje met de naam '3' in de array waar $aap naar wijst.

[ Voor 44% gewijzigd door .oisyn op 29-07-2008 15:01 ]

[Cartman!]

Eens met .oisyn, array_key_exists gebruiken omdat het geen notice oid geeft is bullshit. Met E_ALL|E_STRICT komt er geen enkele fout in het stukje van hierboven. Test het zelf maar :

PHP:

error_reporting(E_ALL|E_STRICT);

$aap[1] = 2;
var_dump(isset($aap[0]));
var_dump(isset($aap[1]));
var_dump(isset($noot[0]));

werkt precies zoals je zou verwachten...

[Verwijderd]

Sterker nog, als isset wel een notice zou geven is het erg lastig.
Je weet dan dat een variabele niet geset kan zijn, je wil daaromheen programmeren met een isset en dan zou PHP een notice geven...

Het is juist omgekeerd, array_key_exists is de functie die notices geeft als je em op niet bestaande zaken laat checken (zoals het voorbeeld wat .oisyn al gaf).

PHP:

<?php
   error_reporting(E_ALL|E_STRICT); 

   $a = array();

   var_dump(array_key_exists('b', $a['a']));
   var_dump(isset($a['a']['b']));
?>

Daarbij geeft nummer 1 dus een notice terwijl nummer 2 gewoon werkt.

[ Voor 25% gewijzigd door Verwijderd op 29-07-2008 16:27 ]

[Cartman!]

Verwijderd schreef op dinsdag 29 juli 2008 @ 16:24:
Sterker nog, als isset wel een notice zou geven is het erg lastig.
Je weet dan dat een variabele niet geset kan zijn, je wil daaromheen programmeren met een isset en dan zou PHP een notice geven...

sterk

[Verwijderd]

Verwijderd schreef op dinsdag 29 juli 2008 @ 16:24:
Sterker nog, als isset wel een notice zou geven is het erg lastig.
Je weet dan dat een variabele niet geset kan zijn, je wil daaromheen programmeren met een isset en dan zou PHP een notice geven...

Het is juist omgekeerd, array_key_exists is de functie die notices geeft als je em op niet bestaande zaken laat checken (zoals het voorbeeld wat .oisyn al gaf).

PHP:

<?php
   error_reporting(E_ALL|E_STRICT); 

   $a = array();

   var_dump(array_key_exists('b', $a['a']));
   var_dump(isset($a['a']['b']));
?>

Daarbij geeft nummer 1 dus een notice terwijl nummer 2 gewoon werkt.

$a[ "a" ]; is dan ook geen array, nogal wiedes dat dat ding een notice en/of warning geeft.

PHP:

<?php

  error_reporting( E_ALL | E_STRICT );

  $foo = array();

  var_dump( isset( $foo[ "bar" ] ) );
  var_dump( array_key_exists( "bar", $foo ) );

?>

Met als output:

code:

simon@aardbei:~$ php array.php 
bool(false)
bool(false)

Wees alsjeblieft secuur met je voorbeelden (nu maar hopen dat ik zelf geen foutje heb gemaakt ). Array key exists kijkt natuurlijk of er een key in een array bestaat, als je hem dan een niet bestaande array opgeeft (of iets van een ander type) ga je altijd een notice maken.

Het is gewoon een feit dat vooraf variabelen definieren altijd "the way to go" is en een beetje de standaard in de industrie. Zo weet iemand precies wat er in je script leeft en wat hij overal in kan verwachten als je dit erbij zou zetten

[ Voor 7% gewijzigd door Verwijderd op 29-07-2008 16:44 ]

[.oisyn]

Verwijderd schreef op dinsdag 29 juli 2008 @ 16:42:
Het is gewoon een feit dat vooraf variabelen definieren altijd "the way to go" is

Uhm, als je deze discussie hebt gevolgd dan kun je al aanvoelen dat het helemaal geen feit is. Of ben jij nu ineens alwetend? Het is jouw mening. Die blijkbaar niet door iedereen wordt gedeeld.

. Zo weet iemand precies wat er in je script leeft en wat hij overal in kan verwachten als je dit erbij zou zetten

Wat is dan precies de toegevoegde waarde van een bestaande variabele die null is, tov een niet-bestaande variabele?

[Verwijderd]

@simonkey:

Ik zeg dan ook helemaal niet dat het gedrag van PHP in deze onlogisch is, sterker nog het is erg logisch.

Het voorbeeld was een voorbeeld om aan te geven waar dat array_key_exists een notice geeft waar isset dat niet geeft, de stelling was dat dit in dergelijke situatie precies andersom was.

[Verwijderd]

Verwijderd schreef op dinsdag 29 juli 2008 @ 16:46:
@simonkey:

Ik zeg dan ook helemaal niet dat het gedrag van PHP in deze onlogisch is, sterker nog het is erg logisch.

Het voorbeeld was een voorbeeld om aan te geven waar dat array_key_exists een notice geeft waar isset dat niet geeft, de stelling was dat dit in dergelijke situatie precies andersom was.

Was me niet helemaal duidelijk, kwam ook pas net binnenvallen en op mij kwam het over dat je het vreemd vond dat array_key_exists() een notice maakte

.oisyn schreef op dinsdag 29 juli 2008 @ 16:44:
[...]

Uhm, als je deze discussie hebt gevolgd dan kun je al aanvoelen dat het helemaal geen feit is. Of ben jij nu ineens alwetend? Het is jouw mening. Die blijkbaar niet door iedereen wordt gedeeld.


[...]

Wat is dan precies de toegevoegde waarde van een bestaande variabele die null is, tov een niet-bestaande variabele?

Zo spreek ik me uit. Ik ben zeer zeker niet alwetend en al helemaal niet op het gebied van PHP aangezien ik dat eigenlijk maar weinig gebruik.

Voor mij is het toegevoegde voordeel dat ik altijd mijn variabelen kan checken via $foo == Null in plaats van dat ik het hele setje hoef te typen en ik bovenin een bestand al snel kan zien wat er allemaal in zit (of hoort).

Kort door de bocht wat ik er zover van snap in PHP is dat er ruwweg maar twee scopes zijn. Een global scope en een function scope. Variabelen die gedefinieerd worden binnen een brace-delimited block leven ook daarbuiten.

Dat is gewoon hoe PHP in den beginne is ontworpen en wat je eigenlijk krijgt als je een taal laat ontwerpen door minder ervaren mensen. Het is "verfrissend".

Laten we maar eens kijken of de introductie van namespaces in PHP 6 een verschil gaat maken

[ Voor 14% gewijzigd door Verwijderd op 29-07-2008 16:53 ]

[Verwijderd]

Verwijderd schreef op dinsdag 29 juli 2008 @ 16:49:
[...]

Was me niet helemaal duidelijk, kwam ook pas net binnenvallen en op mij kwam het over dat je het vreemd vond dat array_key_exists() een notice maakte

Nofi, maarruh: Lees de draad voor je blaat

Verwijderd schreef op dinsdag 29 juli 2008 @ 16:49:
[...]
Voor mij is het toegevoegde voordeel dat ik altijd mijn variabelen kan checken via $foo == Null in plaats van dat ik het hele setje hoef te typen

Huh? Hoe is dat anders dan isset of is_null ?

Zie: http://nl.php.net/manual/en/types.comparisons.php

[ Voor 36% gewijzigd door Verwijderd op 29-07-2008 16:57 ]

[Grijze Vos]

Snake schreef op maandag 28 juli 2008 @ 13:51:

PHP:

$var = null;

if(isset($_POST['var']))
{
    $var = $_POST['var'];
}

Als iets null mag zijn moet je het bij het gebruik sowieso checken of die var null is of niet, dus dan maakt die null initialisatie echt niks uit in dit voorbeeld.

PHP:

$var = null;

if(isset($_POST['var']))
{
    $var = $_POST['var'];
}

if(!is_null($var))
{
  // doe iets met $var
}

is identiek aan:

PHP:

if(isset($_POST['var']))
{
    $var = $_POST['var'];
}

if(!is_null($var))
{
  // doe iets met $var
}

[Verwijderd]

Verwijderd schreef op dinsdag 29 juli 2008 @ 16:55:
[...]

Nofi, maarruh: Lees de draad voor je blaat


[...]

Huh? Hoe is dat anders dan isset of is_null ?

Het is in ieder geval korter en meer mijn stijl, zoals jij ook je eigen stijl hebt. Overigens maakt het in geval van het omgaan met $_POST en $_GET variabelen natuurlijk niks uit Tenzij je je eigen klassen hebt om daar mee om te gaan en die alles al voor je afhandelen.

_{Zoals net hier boven me wordt aangehaald.}

[ Voor 28% gewijzigd door Verwijderd op 29-07-2008 16:59 ]

[.oisyn]

Verwijderd schreef op dinsdag 29 juli 2008 @ 16:49:
Voor mij is het toegevoegde voordeel dat ik altijd mijn variabelen kan checken via $foo == Null in plaats van dat ik het hele setje hoef te typen

Tja, isset($foo) tov $foo == null. Scheelt welgeteld 1 teken in het voordeel van de isset().

en ik bovenin een bestand al snel kan zien wat er allemaal in zit (of hoort).

Maar bovenin je bestand kun je ook niet zien welke classes erin staan, of welke functies. Die polluten óók de global namespace.

Kort door de bocht wat ik er zover van snap in PHP is dat er ruwweg maar twee scopes zijn. Een global scope en een function scope. Variabelen die gedefinieerd worden binnen een brace-delimited block leven ook daarbuiten.

Maar niet ervoor. Tijdelijke temporary variabelen ook van tevoren definieren levert alleen maar extra clutter, plus het feit dat de lifetime van die variabelen dan een stuk minder duidelijk wordt.

Dat is gewoon hoe PHP in den beginne is ontworpen en wat je eigenlijk krijgt als je een taal laat ontwerpen door minder ervaren mensen. Het is "verfrissend".

*proest*. Het rommeltje dat PHP heet verfrissend noemen, ja zo kun je er ook tegenaan kijken

[Verwijderd]

Verwijderd schreef op dinsdag 29 juli 2008 @ 16:57:
[...]


Het is in ieder geval korter en meer mijn stijl, zoals jij ook je eigen stijl hebt. Overigens maakt het in geval van het omgaan met $_POST en $_GET variabelen natuurlijk niks uit Tenzij je je eigen klassen hebt om daar mee om te gaan en die alles al voor je afhandelen.

_{Zoals net hier boven me wordt aangehaald.}

Korter om meer code neer te zetten... das logisch.

.oisyn schreef op dinsdag 29 juli 2008 @ 17:00:
[...]
Tja, isset($foo) tov $foo == null. Scheelt welgeteld 1 teken in het voordeel van de isset().

Je snapt toch zelf ook wel dat:

( ! is_null ( $foo ) ) niet korter is dan $foo!=null?

En die extra nutteloze regels code bovenin zien we dan maar ff over het hoofd

[ Voor 27% gewijzigd door Verwijderd op 29-07-2008 17:07 ]

[Patriot]

Verwijderd schreef op dinsdag 29 juli 2008 @ 16:57:
[...]


Het is in ieder geval korter en meer mijn stijl, zoals jij ook je eigen stijl hebt. Overigens maakt het in geval van het omgaan met $_POST en $_GET variabelen natuurlijk niks uit Tenzij je je eigen klassen hebt om daar mee om te gaan en die alles al voor je afhandelen.

_{Zoals net hier boven me wordt aangehaald.}

Ok, om even op het onderwerp "eigen stijl" in te haken. Je zegt dat het gebruiken van een vergelijking met null meer jouw stijl is dan het gebruiken van is_null(). Is het dan ook niet zo dat het vooraf definiëren net zo goed een eigen stijl is? Ik bedoel, ik kan me best voorstellen dat als je het gewend bent je het graag gebruikt. Maar dat maakt code toch niet ranzig als iemand het niet doet?

Dat is een beetje mijn punt. Snake viel enorm over het feit dat niet alle variabelen vooraf gedefinieerd werden, iets dat mijns inziens helemaal niet ranzig is maar in het geval van PHP gewoon een kwestie van werken op een manier die jij lekker vind. Er is niets mis met het vooraf definiëren, maar ik ben niet van mening dat niet vooraf definiëren slecht zou zijn.

[Verwijderd]

.oisyn schreef op dinsdag 29 juli 2008 @ 17:00:
[...]

Tja, isset($foo) tov $foo == null. Scheelt welgeteld 1 teken in het voordeel van de isset().


[...]

Maar bovenin je bestand kun je ook niet zien welke classes erin staan, of welke functies. Die polluten óók de global namespace.


[...]

Maar niet ervoor. Tijdelijke temporary variabelen ook van tevoren definieren levert alleen maar extra clutter, plus het feit dat de lifetime van die variabelen dan een stuk minder duidelijk wordt.


[...]

*proest*. Het rommeltje dat PHP heet verfrissend noemen, ja zo kun je er ook tegenaan kijken

Check de aanhalingstekens Het is ook niet mijn eerste taal of iets ook niet degene waar ik het liefste in frut.

De lifetime van de variabele, tsja, alles wat je binnen je blokken doet schiet toch de global namespace in (behalve function scope) dus ze leven allemaal tot het einde van execution, of je ze nou eerder of later start.

Dan kunnen we natuurlijk nog gaan profilen of isset() langzamer is dan is_null() of == Null maar dat zal elkaar ook wel niet veel ontlopen. Daarbij moet je zoals ik ook in mijn vorige post al aanhaalde toch altijd al via isset POST en GET variabelen checken.

Patriot schreef op dinsdag 29 juli 2008 @ 17:02:
[...]


Ok, om even op het onderwerp "eigen stijl" in te haken. Je zegt dat het gebruiken van een vergelijking met null meer jouw stijl is dan het gebruiken van is_null(). Is het dan ook niet zo dat het vooraf definiëren net zo goed een eigen stijl is? Ik bedoel, ik kan me best voorstellen dat als je het gewend bent je het graag gebruikt. Maar dat maakt code toch niet ranzig als iemand het niet doet?

Dat is een beetje mijn punt. Snake viel enorm over het feit dat niet alle variabelen vooraf gedefinieerd werden, iets dat mijns inziens helemaal niet ranzig is maar in het geval van PHP gewoon een kwestie van werken op een manier die jij lekker vind. Er is niets mis met het vooraf definiëren, maar ik ben niet van mening dat niet vooraf definiëren slecht zou zijn.

Daar zou je het in het geval van PHP inderdaad onder kunnen scharen. PHP is zo los dat dit soort dingen onder stijl vallen.

[ Voor 28% gewijzigd door Verwijderd op 29-07-2008 17:06 ]

[Verwijderd]

Verwijderd schreef op dinsdag 29 juli 2008 @ 17:05:
[...]

Dan kunnen we natuurlijk nog gaan profilen of isset() langzamer is dan is_null() of == Null maar dat zal elkaar ook wel niet veel ontlopen. Daarbij moet je zoals ik ook in mijn vorige post al aanhaalde toch altijd al via isset POST en GET variabelen checken.

Aangezien isset en is_null language constructs zijn zal het waarschijnlijk dezelfde bytecode opleveren wat je ook doet.

En ik check m'n POST en GET variabelen altijd via !is_null, das mijn stijl (en het heeft een paar voordelen die waarschijnlijk alleen in m'n hoofd bestaan).

[ Voor 13% gewijzigd door Verwijderd op 29-07-2008 17:10 ]

[.oisyn]

Verwijderd schreef op dinsdag 29 juli 2008 @ 17:05:
De lifetime van de variabele, tsja, alles wat je binnen je blokken doet schiet toch de global namespace in (behalve function scope) dus ze leven allemaal tot het einde van execution, of je ze nou eerder of later start.

Ik doelde op de semantische lifetime voor de programmeur , niet op de daadwerkelijke lifetime van de variabelen die tot het eind der script lopen als je ze niet unset(). Ik vind het ook handig om variabelen die idd werkelijk in het hele script gebruikt gaan worden op een overzichtelijke plek te definieren. Voor variabelen die dat niet doen vind ik dat juist onhandig, omdat ze dan (in mijn ogen) een heel andere (veel significantere) betekenis gaan krijgen.

Maar goed, ik ben sowieso meer voor het gebruik van functies en classes, ipv alle code in een monolithisch blok in de global scope te zetten, maar dat staat in feite los van deze discussie.

[ Voor 8% gewijzigd door .oisyn op 29-07-2008 17:13 ]

[iH8]

Verwijderd schreef op dinsdag 29 juli 2008 @ 17:05:

Dan kunnen we natuurlijk nog gaan profilen of isset() langzamer is dan is_null() of == Null maar dat zal elkaar ook wel niet veel ontlopen.

http://nl.php.net/manual/en/function.is-null.php#84161

offtopic:
interessant topic geworden dit, netjes!

[Verwijderd]

iH8 schreef op dinsdag 29 juli 2008 @ 17:14:
[...]


http://nl.php.net/manual/en/function.is-null.php#84161

offtopic:
interessant topic geworden dit, netjes!

Zoals ik al zei dat zal elkaar dus niks ontlopen. Praktisch hetzelfde als " en ' en het parsen op variabelen en dat soort micro spul.

En ik ben het eens met .oisyn, normaal gesproken ook alles in klassen en functies en bar weinig procedureel met bergen en bergen aan "losse" variabelen

[wasigh]

mmm het wordt tijd dat iemand dit topic eens kapot nuanceert

good practice bestaat niet, tenminste niet "an sich". Voor een bepaalde situatie kun je best een best practice hebben maar er is geen "one size fit's all". Persoonlijk ben ik een groot voorstanden van "scrhijven voor onderhoud". De code die ik schrijf moet zo leesbaar mogelijk zijn. Want ik vind: goed leesbaar = goed onderhoudbaar.

In een andere situatie: schrijven voor performance bijvoorbeeld kan een andere code stijl weer veel beter zijn. Het is maar wat je doelstelling is. Er is geen goed of fout, alleen goed of fout voor een bepaalde situatie.

[Cartman!]

Zal ik het nog leuker maken? Ik gebruik eigenlijk altijd !empty()

In combinatie daarmee heeft het ook geen zin om alles te definen als null want empty vind null...empty

Zoals ik eerder zei, als ik iets met een variabele wil doen dan check ik op dat punt of ie bestaat en evt. voldoet aan de voorwaarden voor dat stukje code. Zend Framework genereert geen errors, warnings of notices op variabelen in views die hij niet kan vinden, die laat ie uit zichzelf al leeg dus daarvoor hoef ik het ook niet te doen. Ik fen het eens met wasigh dat code leesbaar moet zijn, gewoon dingen commenten waarvan je denkt dat een ander t niet direct zou begrijpen.