PHP Switch vraagje

[spleethoven]

Ik heb een stuk code waarin ik een swicth case heb staan. Deze doet echter niet wat ik verwacht. Misschien hebben jullie een idee waarom.

ik zou verwachten dat ik volgende code alletwee false zou opleveren. Echter geven ze in beiden gevallen true. Waarom?

PHP:

$arr["test"]="2";
switch($arr["test"])
{
    case "+2":
        echo "true";
        break;
    default:
        echo "false";
        break;
}
echo "<br/>";
echo $arr["test"]=="+2" ? "true" : "false";

output:

true
false

[ Voor 2% gewijzigd door MueR op 18-04-2011 01:06 ]

[KompjoeFriek]

Omdat je string vergelijkingen doet

de dubbele quotes weghalen zou moeten schelen

[frickY]

"2" != "+2".

Indien je dat wel wilt zul je inderdaad integers moeten gebruiken in plaats van strings.

[spleethoven]

Het probleem zit em er in dat op dit moment "2"=="+2" volgens de switch.

[crisp]

frickY schreef op zondag 17 april 2011 @ 23:21:
"2" != "+2".

Indien je dat wel wilt zul je inderdaad integers moeten gebruiken in plaats van strings.

Nee, het punt is juist dat in PHP "2" == "+2" juist wel waar is, zie:

quote: http://nl.php.net/manual/....operators.comparison.php

If you compare a number with a string or the comparison involves numerical strings, then each string is converted to a number and the comparison performed numerically. These rules also apply to the switch statement.

Het zijn beide 'numerical strings'; intern gebruikt php blijkbaar een soort van is_numeric-check...

[Verwijderd]

Heeft PHP geen equals() methode zoals Java heeft?

[Verwijderd]

Huh dat is opzich wel apart omdat het allebei strings zijn.. wat is dan een numerical string? Een string met een nummer erin? Dus de "2" is een numerical string en de "+2" een normale string? Dus omdat de vergelijking een numerical string bevat worden beide naar een integer gecast door php? Dat is niet logisch toch?

Dus "HP Pavilion dv6" == "ipv6" geeft true? xD

[ Voor 7% gewijzigd door Verwijderd op 17-04-2011 23:34 ]

[nemo55]

In dat geval zou de tweede comparison ook true op moeten leveren. Hier lijkt het dus in het eerste geval wel te gebeuren, maar in het tweede geval niet. Doe het dan helemaal wel of niet voor alle vergelijkingen.

Zwaar irritant die ondergrondse type-casting zorgt alleen maar voor verwarring

Ps.
Beide gevallen zouden trouwens op true moeten uitkomen tenzei je strict comparison zou gebruiken wat ook het automatische type-casten voorkomt:
http://www.php.net/manual...#types.comparisions-loose

[ Voor 27% gewijzigd door nemo55 op 17-04-2011 23:48 ]

[crisp]

Verwijderd schreef op zondag 17 april 2011 @ 23:33:
Huh dat is opzich wel apart omdat het allebei strings zijn.. wat is dan een numerical string? Een string met een nummer erin? Dus de "2" is een numerical string en de "+2" een normale string?

Nee, ze zijn beide 'numeric', dus vind er type-juggling plaats:

PHP:

var_dump(is_numeric("2")); // true
var_dump(is_numeric("+2")); // true

Dus omdat de vergelijking een numerical string bevat worden beide naar een integer gecast door php? Dat is niet logisch toch?

Alleen dus als het beide numerical strings zijn

Dus "HP Pavilion dv6" == "ipv6" geeft true? xD

nee dus

[ID-College]

De comparison in PHP vind ik altijd erg tricky. Je kan natuurlijk altijd === gebruiken, maar == geeft vaak ongewenste resultaten. Zeker als ik alleen integers wil hebben, cast ik de data altijd om naar int met (int) ervoor te zetten. Wanneer de waarde dan 0 is, dan was er iig niet alleen een getal ingevuld...

[nemo55]

Je zou het ff moeten checken, maar volgens mij bepaalt het eerste karakter van je string of php gaat lopen typecasten. Is de eerste een numerical dan gaat de engine proberen om een cijfer te maken tot aan het eerstevolgend niet numerieke karakter van de string.

Voorbeeld:
("123string" == "456string") zal uitkomen op de vergelijking (123 == 456)
("string123" == "string456") zal uitkomen op de vergelijking zoals die er staat

[crisp]

nemo55 schreef op zondag 17 april 2011 @ 23:55:
Je zou het ff moeten checken, maar volgens mij bepaalt het eerste karakter van je string of php gaat lopen typecasten. Is de eerste een numerical dan gaat de engine proberen om een cijfer te maken tot aan het eerstevolgend niet numerieke karakter van de string.

Voorbeeld:
("123string" == "456string") zal uitkomen op de vergelijking (123 == 456)
("string123" == "string456") zal uitkomen op de vergelijking zoals die er staat

nope:

PHP:

var_dump(is_numeric("123foo")); // false
var_dump(is_numeric("123bar")); // false

var_dump("123foo" == "123bar"); // false

[Verwijderd]

+2 is eigenlijk hetzelfde als 2. -2 zou weer ongelijk zijn aan 2.

[Verwijderd]

Wat is dan de definitie van een numeric string?

edit± Ah nvm ik snap het..

[ Voor 24% gewijzigd door Verwijderd op 18-04-2011 00:06 ]

[Patriot]

crisp schreef op maandag 18 april 2011 @ 00:01:
[...]

nope:

PHP:

var_dump(is_numeric("123foo")); // false
var_dump(is_numeric("123bar")); // false

var_dump("123foo" == "123bar"); // false

Dat komt doordat de context niet numeriek is en hij niet gaat goochelen met de types (hij doet gewoon een string-vergelijking). Als het om een numerieke context gaat dan is het wel zo dat hij naar de eerste karakters kijkt.

PHP:

var_dump(123 == "123foo"); // true

EDIT: Overigens heeft is_numeric er natuurlijk ook weinig mee te maken. Het gedrag daarvan is heel anders dan de type juggling die PHP doet.

EDIT2: Ik moet overigens zeggen dat als ik het script uit de TS kopiëer ik andere output krijg. Ik krijg de verwachte tweemaal true.

[ Voor 21% gewijzigd door Patriot op 18-04-2011 00:14 ]

[crisp]

Patriot schreef op maandag 18 april 2011 @ 00:11:
[...]
EDIT: Overigens heeft is_numeric er natuurlijk ook weinig mee te maken. Het gedrag daarvan is heel anders dan de type juggling die PHP doet.

is_numeric is wel van belang; PHP doet namelijk ook type-juggling (of eigenlijk: een cast naar number) als beide operands numeric zijn, hence:

PHP:

var_dump("123" == "+123"); // true
var_dump("1000" == "1e3"); // true
var_dump("1" == "1.000"); // true

EDIT2: Ik moet overigens zeggen dat als ik het script uit de TS kopiëer ik andere output krijg. Ik krijg de verwachte tweemaal true.

ik krijg inderdaad ook 2x true

[Patriot]

crisp schreef op maandag 18 april 2011 @ 02:12:
[...]

is_numeric is wel van belang; PHP doet namelijk ook type-juggling (of eigenlijk: een cast naar number) als beide operands numeric zijn, hence:

PHP:

var_dump("123" == "+123"); // true
var_dump("1000" == "1e3"); // true
var_dump("1" == "1.000"); // true

Hmm, ja, natuurlijk. De context is dus numeriek als ofwel minstens één operand numeriek is, of als beide strings zijn die numeriek zijn. Dat zou wel beter in de documentatie kunnen.

Ik blijf het persoonlijk overigens een beetje een WTF vinden dat ze er voor kiezen om "123bar" in een numerieke context te beschouwen als 123.

[MueR]

Patriot schreef op maandag 18 april 2011 @ 02:38:
Dat zou wel beter in de documentatie kunnen.

Hiermee heb je PHP (helaas) samengevat. Er zijn een aantal van deze quirks die af en toe voor enorme hoofdbrekers zorgen. Het is ook meteen een van de grootste zwakheden waarop PHP vaak aangevallen wordt in discussies.

[ Voor 14% gewijzigd door MueR op 18-04-2011 02:43 ]

[ajakkes]

Om de discussie weer ontopic te krijgen:
Toch vreemd dat de uitkomst bij TS anders lijkt te zijn dan bij crisp en Patriot.

Ik zou ook twee keer true verwachten eigenlijk.

[NMe]

De topicstarter zegt vóór zijn code ook dat allebei de checks true geven. Na zijn code spreekt hij zichzelf weer tegen. Ik denk niet dat hij iets anders ziet dan jij en ik.

[ajakkes]

Ah, ik zie het. In dat geval gaat het inderdaad om PHP's 'type-juggling'. Erg vervelend om te debuggen, maar erg voorspelbaar dat het 'm daar in zit.

offtopic:
't valt me nu pas op dat MueR het bericht bewerkt heeft. Meestal wordt er dan wel een reden gegeven.

[Patriot]

ajakkes schreef op maandag 18 april 2011 @ 10:41:

offtopic:
't valt me nu pas op dat MueR het bericht bewerkt heeft. Meestal wordt er dan wel een reden gegeven.

Dat was 1 minuut na zijn originele post en hij voegde deze zin toe: "Het is ook meteen een van de grootste zwakheden waarop PHP vaak aangevallen wordt in discussies."

[MueR]

ajakkes schreef op maandag 18 april 2011 @ 10:41:

offtopic:
't valt me nu pas op dat MueR het bericht bewerkt heeft. Meestal wordt er dan wel een reden gegeven.

offtopic:
Oh, dat ben ik vergeten denk ik. Ik had alleen even code tags toegevoegd. Honest guv!

[NMe]

ajakkes schreef op maandag 18 april 2011 @ 10:41:
Ah, ik zie het. In dat geval gaat het inderdaad om PHP's 'type-juggling'. Erg vervelend om te debuggen, maar erg voorspelbaar dat het 'm daar in zit.

Vervelend om te debuggen valt wel mee, mits je weet dat dit soort dingen kan optreden. Defensief programmeren lost de meeste problemen ermee wel op.

[ajakkes]

Patriot schreef op maandag 18 april 2011 @ 11:32:
[...]


Dat was 1 minuut na zijn originele post en hij voegde deze zin toe: "Het is ook meteen een van de grootste zwakheden waarop PHP vaak aangevallen wordt in discussies."

offtopic:
Nee, ik bedoelde de TS edit van MueR 2 uur na het posten van het bericht. Ik had wel het vermoeden dat dit de code tags waren, maar ben gewend dat dat vermeld wordt. Misschien was het MueR wel die true in false heeft veranderd. .

Tja, je kan het ook zien als een feature van PHP. Het is toch heel vreemd dat een programmeertaal vind dat 2 geen "2" is en dat "2" geen "+2" is. Maar als er plotseling vreemde dingen gebeuren omdat je geen rekening had gehouden met iemand die "false" intypt en iedere keer de melding krijgt dat ie toch echt iets zal moeten invullen kan het in sommige situaties toch wel koppijn veroorzaken. Maar je weet dat een PHP programmeur deze bugs kan veroorzaken.

[ Voor 0% gewijzigd door ajakkes op 18-04-2011 13:41 . Reden: aanhalingstekens om de 2-en waar nodig. ]

[NMe]

ajakkes schreef op maandag 18 april 2011 @ 13:40:
[...]

Tja, je kan het ook zien als een feature van PHP. Het is toch heel vreemd dat een programmeertaal vind dat 2 geen "2" is en dat "2" geen "+2" is.

Nee hoor, vreemd is dat niet. Het is de enige manier waarop je makkelijk voorspelbaar kunt programmeren, omdat je anders dus dit soort problemen kan krijgen. En zelfs als je "2" en "+2" gelijk wil stellen aan 2 is dat nog geen excuus om "2 appels" óók gelijk te maken aan 2 en daarmee "2 appels" ook gelijk te maken aan "2 peren". Wat vervolgens niet helemaal waar is:

PHP:

var_dump("2 appels" == 2);                // true
var_dump("2 peren" == 2);                 // true
var_dump(2 == 2);                         // true
var_dump("2 appels" == "2 peren");        // false
var_dump(((int)"2 appels") == "2 peren"); // true

[ Voor 6% gewijzigd door NMe op 18-04-2011 14:04 ]

[EddoH]

ajakkes schreef op maandag 18 april 2011 @ 13:40:
[...]


Tja, je kan het ook zien als een feature van PHP. Het is toch heel vreemd dat een programmeertaal vind dat 2 geen "2" is en dat "2" geen "+2" is.

Je geeft nu toch gewoon precies het verschil tussen strong-typed en weak-typed talen aan? Hoop niet dat je gaat beweren dat strong-typed talen vreemd zijn

[ Voor 26% gewijzigd door EddoH op 18-04-2011 14:07 ]

[ajakkes]

Ik zou natuurlijk kunnen gaan beweren van wel om de discussie op gang te houden.

Maar dat is zeker geen discussie die hier thuis hoort.

2 appels zijn er natuurlijk ook gewoon 2. En als ik niemand heet, ben ik niemand.
Het enige vreemde aan PHP is dat "twee" geen 2 is.

[Creepy]

Die discussie blijft leuk, en is gezien het oorspronkelijk probleem van de TS ook het daadwerkelijke probleem: leg aan een wiskundige maar eens uit dat "2 appels" + "2 peren" het getal 4 als uitkomst heeft

offtopic:
Ja, + is een optelling en geen concatenation, ik weet het. En daarom juggled PHP de strings naar ints

[ Voor 7% gewijzigd door Creepy op 18-04-2011 16:34 ]

[NMe]

ajakkes schreef op maandag 18 april 2011 @ 14:37:
2 appels zijn er natuurlijk ook gewoon 2. En als ik niemand heet, ben ik niemand.

Als "2 appels" gelijk is aan 2, en "2 peren" ook gelijk is aan 2, dan is de logische gevolgtrekking dat "2 appels" ook gelijk moet zijn aan "2 peren". Dat is niet zo, en daarom is het onlogisch.

[EddoH]

ajakkes schreef op maandag 18 april 2011 @ 14:37:
En als ik niemand heet, ben ik niemand.

Behalve de bekende wiskundige onregelmatigheid, geef je zelf hier al een prachtig voorbeeld trouwens. Ben je niemand als in ' geen persoon/ niet bestaand' , of is jouw naam "niemand" ?

[ Voor 9% gewijzigd door EddoH op 18-04-2011 16:39 ]

[Patriot]

ajakkes schreef op maandag 18 april 2011 @ 14:37:
2 appels zijn er natuurlijk ook gewoon 2. En als ik niemand heet, ben ik niemand.
Het enige vreemde aan PHP is dat "twee" geen 2 is.

"2 appels" is in die zin ook misschien wel een verkeerd voorbeeld omdat het taaltechnisch (de Nederlandse taal, niet de programmeertaal ) niet vreemd is: Het geeft een hoeveelheid aan. De string "10 is een zeer mooi getal" is iets wat in een numerieke context door PHP naar 10 omgezet zal worden en dat is iets gekker omdat 10 in die zin geen hoeveelheid aangeeft.

[ajakkes]

EddoH schreef op maandag 18 april 2011 @ 16:38:
[...]


Behalve de bekende wiskundige onregelmatigheid, geef je zelf hier al een prachtig voorbeeld trouwens. Ben je niemand als in ' geen persoon/ niet bestaand' , of is jouw naam "niemand" ?

Dat was natuurlijk ook de bedoeling.

Dat "true" == true kan ik me bij een taal als PHP nog enigszins voorstellen. Dat "2" == 2 ook. Maar dat "2 is geen 4" == 2 is, is wel een rare keuze.

[EddoH]

Ok.. heb ik je punt gemist Dan weet ik ook niet precies welk punt je nou probeerde te maken.
Dat PHP niet alles interpreteert zoals een mens misschien zou verwachten? Eigenschap van loose-typed, me dunkt.

[Patriot]

EddoH schreef op maandag 18 april 2011 @ 20:34:Eigenschap van loose-typed, me dunkt.

Nee, dat een taal loose-typed is wil niet zeggen dat ze geen logischere manier van omzetten kunnen gebruiken. Ze kunnen er ook gewoon voor kiezen om het te evalueren naar (het in mijn ogen logischere) 0 bijvoorbeeld.

[EddoH]

Patriot schreef op dinsdag 19 april 2011 @ 00:14:
[...]


Nee, dat een taal loose-typed is wil niet zeggen dat ze geen logischere manier van omzetten kunnen gebruiken. Ze kunnen er ook gewoon voor kiezen om het te evalueren naar (het in mijn ogen logischere) 0 bijvoorbeeld.

De eigenschap van loose-typed is dat het implicit type conversion of/en ad-hoc polymorphism gebruikt. Dat jij een bepaalde implicit conversie logisch vindt wil niet zeggen dat ik het logisch vind of de buurman het logisch vindt.

[ Voor 10% gewijzigd door EddoH op 19-04-2011 08:32 ]

[ACM]

EddoH schreef op dinsdag 19 april 2011 @ 08:27:
De eigenschap van loose-typed is dat het implicit type conversion of/en ad-hoc polymorphism gebruikt. Dat jij een bepaalde implicit conversie logisch vindt wil niet zeggen dat ik het logisch vind of de buurman het logisch vindt.

Misschien, maar ik denk dat de meesten een afkapping van een string naar een getal niet logischer vinden dan het behandelen van de hele string als geheel en dan te controleren of het een getal is.

Men verwacht normaliter dat de ==-operator reflexive (x == x levert true op), symmetric (x == y levert hetzelfde op als y == x), transitive (als x == y en x == z, dan ook y == z) en consistent (ongeacht hoe vaak je x == y herhaalt, het resultaat is hetzelfde) is.

NMe bewijst hierboven dat de ==-operator nu niet transitive is in php, althans, niet voor elke willekeurige combinatie van x, y en z (neem x = 2, y = "2 peren" en z = "2 appels"). Je kan trouwens hetzelfde zeggen van een conversie naar 0 voor niet-getal inhoud. Dan krijg je bijvoorbeeld x = 0, y = "appels" en z = "peren".
Waar php hier de fout mee ingaat - imho - is dat ze niet naar de ruimste variabele type casten, maar juist naar de krapste. Als x en y vergeleken worden, dan wordt er in het geval van een int met float voor beide een float-compare gedaan (1 != 1.1), maar als er een string met een int vergeleken wordt, dan wordt daar een int-compare afgedwongen. Het zou correcter zijn dan juist een string-compare te doen (dus 0 -> "0" en 2 -> "2") als een van de operands een (gedeeltelijk) non-numeric string is.

Het moet dus niet 2 == (int)"2 appels" zijn, maar juist (string)2 == "2 appels" zijn, mijns inziens. En of (int)"2 appels" wel 2 op hoort leveren of 0 is dan nog een aparte discussie (0 is meer consistent).

[ Voor 4% gewijzigd door ACM op 19-04-2011 09:07 ]

[Slurpie]

Volgens mij hebben ze daarom voor zulke dingen dan ook === uitgevonden zodat je zeker weet dat het type en de waarde overeen komen. Sowieso is === altijd een betere vergelijkingen dan == imho.

[ACM]

Dat php "2" en 2 standaard als gelijkwaardig beschouwd is best goed te verdedigen als keuze, dat verlies je ook met ===, bovendien is er geen >== of <==, dus je ontkomt er nooit helemaal aan om e.e.a. te dubbelchecken. Het gaat om die wat vreemdere constructies hier waar het in de ogen van de meesten mis gaat.

[Guillome]

Slurpie schreef op dinsdag 19 april 2011 @ 09:11:
Volgens mij hebben ze daarom voor zulke dingen dan ook === uitgevonden zodat je zeker weet dat het type en de waarde overeen komen. Sowieso is === altijd een betere vergelijkingen dan == imho.

Wat mij betreft het slot-antwoord. Gebruik === als je zeker wilt zijn, gebruik == als je flexibel wilt zijn. Hoe dat echter voor een switch case moet...?

[ Voor 5% gewijzigd door Guillome op 19-04-2011 09:28 ]

[Patriot]

EddoH schreef op dinsdag 19 april 2011 @ 08:27:
[...]


De eigenschap van loose-typed is dat het implicit type conversion of/en ad-hoc polymorphism gebruikt. Dat jij een bepaalde implicit conversie logisch vindt wil niet zeggen dat ik het logisch vind of de buurman het logisch vindt.

Mja, dat is wel erg makkelijk, ik wil gewoon zeggen dat een loose-typed taal niet per sé een impliciete conversie hoeft te doen die onlogisch is. Jouw tegenargument lijkt te zijn dat er altijd wel iemand kan zijn die het onlogisch vind, maar dan blijf je bezig

Guillome schreef op dinsdag 19 april 2011 @ 09:27:
[...]

Wat mij betreft het slot-antwoord. Gebruik === als je zeker wilt zijn, gebruik == als je flexibel wilt zijn. Hoe dat echter voor een switch case moet...?

Dat kan niet, als de controle per sé strict moet zijn dan moet je een ifelse gebruiken. In de meeste gevallen kun je dan echter beter van tevoren zorgen dat je een getal krijgt en geen string, er van uitgaande dat een switch op dat moment de beste keuze is natuurlijk.

[RobIII]

Patriot schreef op dinsdag 19 april 2011 @ 10:13:
Dat kan niet

Correct, maar het kan wel met een beetje een workaround:

PHP:

switch(true)
{
  case ($foo === 2):
    return 'X';
  case ($foo === 3):
    return 'Y';
  default:
    return 'Z';
}

[ Voor 4% gewijzigd door RobIII op 19-04-2011 10:31 ]

[ajakkes]

Ik kan me goed vinden in het verhaal van ACM. Prima dat PHP "+2" == 2 true vindt en "true" true vindt, maar het is heel vreemd dat "2a" == 2 ook true is.

Waar deze keuze vandaan komt is voor mij dan ook een grote vraag.

Kiezen voor een loose-typed methode is geen vreemde keuze. Maar appels met peren vergelijken natuurlijk wel.
"true" != "1" maar true == "true" en true == "1" en 1 == "true" en 1 == "1". Verrassend, maar niet echt vreemd.

[EddoH]

Patriot schreef op dinsdag 19 april 2011 @ 10:13:
[...]


Mja, dat is wel erg makkelijk, ik wil gewoon zeggen dat een loose-typed taal niet per sé een impliciete conversie hoeft te doen die onlogisch is. Jouw tegenargument lijkt te zijn dat er altijd wel iemand kan zijn die het onlogisch vind, maar dan blijf je bezig

Precies! Daarom is de discussie of een implicit conversie bij een loose-typed taal 'vreemd' is ook wat scheef mijn insziens: het is onlosmakeend verbonden met het concept loose-typed. Wil je het voorkomen: strong-typed.

[ACM]

ajakkes schreef op dinsdag 19 april 2011 @ 10:26:
Waar deze keuze vandaan komt is voor mij dan ook een grote vraag.

Zo te zien doet perl het ook op deze manier. Wellicht dat ze bij php niet zelf die keuze hebben gemaakt destijds Maar python doet het bijv weer niet (zelfs 1 en "1" zijn daar niet equal, en "1a" is niet via int(...) naar int te casten).

EddoH schreef op dinsdag 19 april 2011 @ 10:55:
Precies! Daarom is de discussie of een implicit conversie bij een loose-typed taal 'vreemd' is ook wat scheef mijn insziens: het is onlosmakeend verbonden met het concept loose-typed. Wil je het voorkomen: strong-typed.

Je hebt hier gelijk, maar het punt van discussie is niet de impliciete conversie an sich. Maar het onvoorspelbare karakter dat php er aan geeft.

Waarom zijn deze drie allemaal equal aan elkaar?

PHP:

$x = "2";
$y = "+2";
$z = "2.0";

't Zijn alledrie strings, dus er is geen implicit conversion nodig, toch levert een == op dat ze alledrie equal zijn. Als er nou nog een kale integer of float bij had gezeten, vooruit, maar dit gedrag? Als je dus strings helemaal veilig wilt vergelijken, dan moet je verplicht strcmp gebruiken, maar dat is weer niet toepasbaar op veel plekken waar php's vergelijking impliciet gebruikt wordt.

Check dit scriptje bijvoorbeeld:

PHP:

$x = "2";
$y = "+2";
$z = "2.0";

var_dump($x == $y);
var_dump($x == $z);
var_dump($y == $z);

$ar = array();
$ar[$x] = 1;
$ar[$y] = 2;
$ar[$z] = 3;

var_dump($ar);

foreach(array($x, $y, $z) as $i)
{
        switch($i)
        {
                case "2":
                        echo "$i = 2\n";
                        break;
                case "+2":
                        echo "$i = +2\n";
                        break;
                case "2.0":
                        echo "$i = 2.0\n";
                        break;

        }
}

Aangezien x, y en z allemaal equal zijn volgens php... zou je verwachten dat er 1 element in de array zit met waarde 3. Maar er zitten er drie in en als je de uitkomst van de array ziet, zou je verwachten dat uit die foreach weer drie verschillende uitkomsten komen, maar ze zijn allemaal 2 volgens de switch/case...

Kortom, dat 2 = 2.0 en 2 = "2" is prima. Maar "2" != "2.0", het zijn beide strings, dus er zou geen type cast voor moeten komen. Idem voor typecasts waarbij een deel van de waarde wordt weggegooid.

[EddoH]

Ik ben het op zich eens met je eens wat betreft bovenstaand verhaal, maar ik ging meer in op:

ajakkes schreef op maandag 18 april 2011 @ 13:40:
Tja, je kan het ook zien als een feature van PHP. Het is toch heel vreemd dat een programmeertaal vind dat 2 geen "2" is en dat "2" geen "+2" is.

Bovenstaande quote impliceerde de 'vreemdheid' van strong-typing...

Jullie PHP'ers gaan maar discussieren over of PHP het allemaal logisch oplost