isset en waarde direct binnenhalen
Pagina: « vorige 1 2 3 volgende »
Kris Peeters op 14/11/2013 13:24:13:
Als $_GET['id'] niet bestaat, is $_GET['id'] zeker niet groter dan 5. Dus kan de if simpelweg een false geven.
Als $_GET['id'] niet bestaat, is $_GET['id'] zeker niet groter dan 5. Dus kan de if simpelweg een false geven.
Tot hier kon ik je nog volgen en enigszins ermee instemmen (hoewel ik het nooit zal doen, fouten onderdrukken etc), maar hier ga je mis. En dit is ook de basis, wat mij betreft, waarom php niet kan doen wat Ozzie eigenlijk wil.
Als jij zegt "$_GET['id'] bestaat niet en is dus niet groter dan 5 en dus moet het false zijn" (mijn interpretatie) dan zeg je eigenlijk, impliciet, dat als ik andersom zou doen ($_GET['id'] <= 5) dat daar true uit zou moeten komen. Simpele logica. Is iets niet groter dan 5, dan is het 5 of kleiner. Maar hier is dat ook niet het geval. $_GET['id'] bestaat immers niet en is dus, de beste vertegenwoordiging van iets dan niet bestaat: NULL. Maar NULL is niets en is nergens mee te vergelijken. NULL == NULL levert eigenlijk false op en NULL != NULL eigenlijk ook (hoewel niet helemaal het geval in php, in php kan je wel vergelijken met NULL).
Daarmee kom je wat mij betreft tot de bodem van de zaak. Want wat Ozzie wil is dat als hij een niet bestaande key in een array aanroept dat hij zonder fout/waarschuwing en zonder te hoeven checken toch een waarde terugkrijgt (mijn interpretatie). Maar dat kan echter niet. Wat voor waarde moet php hangen aan een variabele die niet bestaat? NULL is wederom het antwoord, want elke andere (echte) waarde zou betekenen dat je er al een duiding aan geeft (het type van de variabele bijvoorbeeld) en is te vergelijken met andere variabelen, terwijl NULL dat niet is.
Oftewel, in elk zichzelf respecterende taal kan niet wat Ozzie graag wil. Waarbij je wat mij betreft nog kan betogen dat php niet een zichzelf respecterende taal is, maar in dit geval wel correct.
Gewijzigd op 14/11/2013 16:39:51 door Erwin H
Maar praktisch is het wel op te lossen. Ik gebruik soms een pre-processor die alles uit (met name) $_POST haalt dat ik er in eerste instantie niet in heb gestopt. Gewoon een keiharde unset(), zelfs op bijvoorbeeld een empty() na wat stringoperaties.
Daarna wordt alle code veel eenvoudiger, zolang je maar een uitstapje langs de pre-processor forceert.
Beetje nuanceren dan...
Code (php)
1
2
3
4
5
2
3
4
5
<?php
$array = ['foo' => 'foo'];
$foo = $array['foo']; // Waarde bestaat en wordt direct teruggegeven, $foo = 'foo';
$bar = $array['bar']; // Waarde bestaat niet, $bar = null;
?>
$array = ['foo' => 'foo'];
$foo = $array['foo']; // Waarde bestaat en wordt direct teruggegeven, $foo = 'foo';
$bar = $array['bar']; // Waarde bestaat niet, $bar = null;
?>
In plaats van:
Code (php)
Ander voorbeeld:
Code (php)
Gewijzigd op 14/11/2013 16:56:41 door Ozzie PHP
Ozzie PHP op 14/11/2013 16:55:27:
>> Want wat Ozzie wil is dat als hij een niet bestaande key in een array aanroept dat hij zonder fout/waarschuwing en zonder te hoeven checken toch een waarde terugkrijgt (mijn interpretatie).
Beetje nuanceren dan...
Beetje nuanceren dan...
Merk op dat je dan het probleem gewoon verlegt. Want dan krijg je de nodige check gewoon bij de eerstvolgende regel waar je $bar gebruikt. Zelfs als php er overigens geen fout of waarschuwing op geeft.
$bar = null is iets wat je nooit zou moeten doen, omdat null nogmaals niets is. Het is in feite hetzelfde als helemaal niets declareren. Wat je wil is ofwel check op null (en zo ja daar adequaat op handelen), of zorgen dat je een default waarde in $bar zet. Het laatste is iets dat php niet kan, het eerste is wat jij niet wilt. Tja, wat dan?
Erwin H op 14/11/2013 16:39:09:
Als jij zegt "$_GET['id'] bestaat niet en is dus niet groter dan 5 en dus moet het false zijn" (mijn interpretatie) dan zeg je eigenlijk, impliciet, dat als ik andersom zou doen ($_GET['id'] <= 5) dat daar true uit zou moeten komen. Simpele logica.
Nee, vind ik niet.
De simpele logica waar jij over spreekt, is enkel waar indien je over getallen spreekt.
Freddy is niet groter dan 5. Freddy is ook niet kleiner dan 5.
Het ene impliceert niets over het andere, tenzij je op voorhand vast legt dat we over rationele* getallen spreken.
Wederom wil ik hier de javascript visie toepassen.
Javascript returnt een NaN.
Een NaN wordt in een if geëvalueerd als false.
(* het wordt pas echt leuk als we met imaginaire / complexe getallen werken. Dan zijn de concepten < en > helemaal niet meer zo evident)
Gewijzigd op 14/11/2013 17:12:58 door Kris Peeters
Ward van der Put op 14/11/2013 16:53:35:
Erwin, dat is inderdaad een sterke observatie!
Maar praktisch is het wel op te lossen. Ik gebruik soms een pre-processor die alles uit (met name) $_POST haalt dat ik er in eerste instantie niet in heb gestopt. Gewoon een keiharde unset(), zelfs op bijvoorbeeld een empty() na wat stringoperaties.
Daarna wordt alle code veel eenvoudiger, zolang je maar een uitstapje langs de pre-processor forceert.
Maar praktisch is het wel op te lossen. Ik gebruik soms een pre-processor die alles uit (met name) $_POST haalt dat ik er in eerste instantie niet in heb gestopt. Gewoon een keiharde unset(), zelfs op bijvoorbeeld een empty() na wat stringoperaties.
Daarna wordt alle code veel eenvoudiger, zolang je maar een uitstapje langs de pre-processor forceert.
Hmm, deze begrijp ik niet helemaal, maar dat ligt waarschijnlijk aan mijn kennis van pre-processors en wat die kunnen (lees: gebrek aan kennis).
Toevoeging op 14/11/2013 17:14:43:
Kris Peeters op 14/11/2013 17:11:16:
Nee, vind ik niet.
De simpele logica waar jij over spreekt, is enkel waar indien je over getallen spreekt.
Freddy is niet groter dan 5. Freddy is ook niet kleiner dan 5.
Het ene impliceert niets over het andere, tenzij je op voorhand vast legt dat we over rationele getallen spreken.
De simpele logica waar jij over spreekt, is enkel waar indien je over getallen spreekt.
Freddy is niet groter dan 5. Freddy is ook niet kleiner dan 5.
Het ene impliceert niets over het andere, tenzij je op voorhand vast legt dat we over rationele getallen spreken.
Precies en dus kan je ook niet false teruggeven als je kijkt of Freddy groter is dan 5, nog kan je true teruggeven. Je moet een error gooien want je kan het niet vergelijken. Precies wat ik dus betoog.
Quote:
Wederom wil ik hier de javascript visie toepassen.
Javascript returnt een NaN.
Een NaN wordt in een if geëvalueerd als false.
Javascript returnt een NaN.
Een NaN wordt in een if geëvalueerd als false.
Afhankelijk van hoe het gebruikt wordt wat mij betreft dus ook fout. Als je een NaN met 5 vergelijkt moet het een fout opleveren, geen false, geen true.
Erwin H op 14/11/2013 17:12:05:
Als je een NaN met 5 vergelijkt ...
Okay, stel: a is geen getal
a < 5 levert de NaN
Het is de operator < die dat aan het systeem returnt.
De NaN wordt aan de if gepresenteerd
De if evalueert dat als false
De if geeft false terug.
Gewijzigd op 14/11/2013 17:21:22 door Kris Peeters
Dat is toch prima? Ah, de waarde is null... hij bestaat blijkbaar niet! Vervolgens onderneem ik gepaste actie.
Het gaat mij dus om het feit dat je 2x een array-key aanspreekt als deze bestaat. Vergelijk het met dit: stel je wil een broek kopen. Je wandelt een winkel binnen, en daar hangt precies jouw exemplaar. In plaats van dat je de broek gelijk meeneemt, wandel je eerst de winkel uit. Vervolgens wandel je de winkel weer in en neem je alsnog de broek mee. En hebben ze die broek in die winkel toevallig niet, dan krijg je nul op het rekest... of beter gezegd NULL op het rekest :)))
>> Hmm, deze begrijp ik niet helemaal, maar dat ligt waarschijnlijk aan mijn kennis van pre-processors en wat die kunnen (lees: gebrek aan kennis).
Ward bedoelt dat ie z'n form input checkt voordat ie er iets mee gaat doen. Als er keys in de POST data staan, die niet uit het formulier afkomstig zijn (ofwel dubieuze data) dan filtert hij die eruit. Van de vereiste keys checkt hij of ze bestaan. Pas dan gaat ie er iets mee doen, maar op het moment dat ie er iets mee gaat doen, weet hij dus ook dat ze (de keys) bestaan.
Ozzie PHP op 14/11/2013 17:19:46:
>> $bar = null is iets wat je nooit zou moeten doen, omdat null nogmaals niets is.
Dat is toch prima? Ah, de waarde is null... hij bestaat blijkbaar niet! Vervolgens onderneem ik gepaste actie.
Dat is toch prima? Ah, de waarde is null... hij bestaat blijkbaar niet! Vervolgens onderneem ik gepaste actie.
Dus:
Ben ik nu gek, of is het gewoon hetzelfde als:
Waarbij alleen de tweede op de juiste plek checkt en de eerste niet?
Daar kan ik niet over oordelen :-/
Lees mijn opmerking hierboven...
"Het gaat mij dus om het feit dat je 2x een array-key aanspreekt..."
Kris Peeters op 14/11/2013 17:19:11:
Okay, stel: a is geen getal
a < 5 levert de NaN
Het is de operator < die dat aan het systeem returnt.
De NaN wordt aan de if gepresenteerd
De if evalueert dat als false
De if geeft false terug.
Erwin H op 14/11/2013 17:12:05:
Als je een NaN met 5 vergelijkt ...
Okay, stel: a is geen getal
a < 5 levert de NaN
Het is de operator < die dat aan het systeem returnt.
De NaN wordt aan de if gepresenteerd
De if evalueert dat als false
De if geeft false terug.
In dat geval is wat mij betreft de NaN goed, de false niet. Het is niet false, het kan namelijk niet geevalueerd worden.
Volgens de stricte regels van de logica is a>=5 als a<5 niet geldt en dat is in dit geval ook niet het geval. Wat je namelijk dan krijgt:
En dit klopt niet. Als ik het namelijk omdraai krijg ik het andere:
Volgens elke logica kan dit niet.
Maar dit begint natuurlijk wel erg puriteins te worden....
Code (php)
1
2
3
4
5
2
3
4
5
if (a<5) {
alert 'yippy';
} else {
alert 'niet yippy, groter of gelijk 5 - ofwel geen getal';
}
alert 'yippy';
} else {
alert 'niet yippy, groter of gelijk 5 - ofwel geen getal';
}
Gewijzigd op 14/11/2013 17:36:12 door Kris Peeters
Ozzie PHP op 14/11/2013 17:26:57:
"Het gaat mij dus om het feit dat je 2x een array-key aanspreekt..."
Maar wat is dat nu voor punt? Je wil dus liever in de rest van je applicatie op null testen, dan twee keer een array key aanspreken? Wat is de reden daarachter, wat is er nu op tegen om de juiste checks uit te voeren? Is het gewoon teveel tik werk of zo? Schrijf er dan een keer een functie voor, ben je er verder vanaf. Zoals uitgelegd kan je dat niet van php verwachten, maar niets staat je in de weg om het zelf te doen natuurlijk.
Misschien ben ik dan gewoon gek inderdaad, maar dit slaat (voor mij) nergens op.... maar dat hoeft verder gelukkig geen beletsel te zijn om er verder over door te gaan.
Toevoeging op 14/11/2013 17:35:16:
Kris Peeters op 14/11/2013 17:30:37:
if (a<5) {
alert 'yippy';
} else {
alert 'niet yippy, groter of gelijk 5 - ofwel geen getal';
}
alert 'yippy';
} else {
alert 'niet yippy, groter of gelijk 5 - ofwel geen getal';
}
Nee dus, want doe je andersom krijg je de andere uitkomst. Dus dan wordt het:
Code (php)
1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
if (a<5) {
alert 'yippy';
} else {
alert 'niet yippy, groter of gelijk 5 - ofwel geen getal';
}
if (a>=5) {
alert 'niet yippy, groter of gelijk 5 - ofwel geen getal';
} else {
alert 'yippy';
}
alert 'yippy';
} else {
alert 'niet yippy, groter of gelijk 5 - ofwel geen getal';
}
if (a>=5) {
alert 'niet yippy, groter of gelijk 5 - ofwel geen getal';
} else {
alert 'yippy';
}
Maar nu krijg je bij geen getal 'yippy' en dat klopt dus voor geen meter meer.
Gewijzigd op 14/11/2013 17:37:01 door Erwin H
Een operator is een functie !!!
Alleen; ze ziet er niet uit als een functie.
Kris, dat begrijp ik, maar dat doet (wat mij betreft) niets af aan het feit dat de antwoorden tegen de logica ingaan. Daarmee is het niet zo dat ik vind dat dus javascript slecht is of weet ik wat, maar vanuit een puriteinse invalshoek zou het niet zo moeten zijn als het is.
De reden is dat arrays in PHP traag zijn. Vergelijk een array met een boekenkast. Als je een array aanspreekt moet je eerst de boekenkast inklimmen en het juiste boek zoeken. Het is handiger, om als het boek bestaat, dit gelijk mee te nemen in plaats van dat je eerst gaat kijken of het bestaat, vervolgens weer terug naar je plek gaat, en daarna weer de boekenkast in duikt om datzelfde boek, waarvan je zojuist hebt geconstateerd dat het bestaat, uit de boekenkast te pakken.
EN JA... dit is een gechargeerd voorbeeld, maar in de praktijk werkt het natuurlijk wel zo. Keer op keer ga je kijken of een boek bestaat, ga je weer terug naar je plek, en ga je het vervolgens ophalen. En ja, natuurlijk gaat dat in de praktijk heeeeeeeel erg snel. Maar het gaat om het principe, dat ik het niet logisch vind, en dat je daarbij onnodig vertraging ondervindt (hoewel je daar dus in de praktijk niet veel van zal merken).
Nou ja, dan kan ik je een antwoord geven dat je dan moet kijken naar andere datastructuren, maar dat ga ik (hier) niet doen. Het antwoord op je vraag is wat mij betreft: nee dat kan niet en dat is wat mij betreft logisch.
Ik ben aan het virtueel-scheen-schoppen ...
Maar dat is geen reden om niet in te gaan op de argumenten.
Een quote van Freeman Dyson (theoretisch fysicus) (zie http://www.youtube.com/watch?gl=BE&v=8xFLjUt2leM )
Quote:
The prevailing dogmas may be right, but they still need to be challenged.
Erwin, je ziet het echt verkeerd. De implicatie die jij maakt, klopt niet.
Het is niet omdat (a < 5) false geeft dat (a >= 5) automatisch juist is.
Nog eens; dat is enkel het geval wanneer a een getal is. Een rationeel getal dan nog wel.
Als je niet op voorhand afspreekt dat a een getal is, is die implicatie niet terecht.
Kris Peeters op 14/11/2013 17:49:39:
Als je niet op voorhand afspreekt dat a een getal is, is die implicatie niet terecht.
Exact: daarom gooi je elke a die geen getal is waar je een getal verwacht gewoon weg. En dan met unset() en niet met null of ''. Anders dan bij andere omgevingen verwijst null bij PHP niet naar de eeuwige jachtvelden.
Kris Peeters op 14/11/2013 17:49:39:
Laat me toch even herhalen dat ik niemand wil pushen om de ene of de andere conclusie echt toe te passen.
Ik ben aan het virtueel-scheen-schoppen ...
Maar dat is geen reden om niet in te gaan op de argumenten.
Ik ben aan het virtueel-scheen-schoppen ...
Maar dat is geen reden om niet in te gaan op de argumenten.
En dat mage ik dan wel, vandaar dat ik er ook op in blijf gaan.
Kris Peeters op 14/11/2013 17:49:39:
De implicatie die jij maakt, klopt niet.
Het is niet omdat (a < 5) false geeft dat (a >= 5) automatisch juist is.
Nog eens; dat is enkel het geval wanneer a een getal is. Een rationeel getal dan nog wel.
Het is niet omdat (a < 5) false geeft dat (a >= 5) automatisch juist is.
Nog eens; dat is enkel het geval wanneer a een getal is. Een rationeel getal dan nog wel.
Hoezo, is dat een natuurwet?
Nee natuurlijk, het is gewoon een afspraak, of iets met iets anders vergeleken kan worden. Zolang we maar afspreken hoe, kunnen we alles met elkaar vergelijken. Als we afspreken dat we een string karakter voor karakter met elkaar vergelijken, dan kunnen we zeggen welke string de grootste is.
Als we afspreken dat we een getal als string zien en het zo met een string vergelijken, dan kunnen we getallen met strings vergelijken.
Etc etc. Dat alleen getallen met elkaar kunnen vergelijken is echte onzin.
En dan, als we hebben afgesproken dat twee waardes vergelijkbaar zijn, dan kan je bepalen of a < b geldt, of a = b geldt, of a > b geldt. Een van de drie is correct, de rest niet. Daaruit volgt dat als a > b geldt, dat a <= b niet kan gelden. En al a > b niet geldt (false oplevert) dan moet a <= b gelden (true). Die twee kunnen niet beide false opleveren voor dezelfde a en b.
Maar, het punt zit hem in a en b die niet te vergelijken zijn. In dat geval zeg ik die zou geen resultaat moeten opleveren in een vergelijking. Geen true en geen false. True en false impliceren wat mij betreft dat de vergelijking wel mogelijk is en dus is de enige optie dat als a en b niet vergelijkbaar zijn dat er een foutmelding moet volgen. Net als dat als je twee arrays bij elkaar wilt optellen je geen resultaat krijgt. Die kan je niet bij elkaar optellen als we niet hebben afgesproken hoe en dus krijg je geen false, maar een foutmelding.