Wat is er mis met PHP?

[Janoz]

alex3305 schreef op dinsdag 04 maart 2014 @ 23:07:
soms toevallig goed gaat? Kun je misschien wat duidelijker zijn, want dat vind ik nou niet echt hoopvol klinken voor een programmeertaal

Neem bijvoorbeeld de strpos functie. Het kan heel goed lijken dat deze gewoon keurig werkt, totdat je needle een keer aan het begin van je haystack staat.

[!null]

Janoz schreef op woensdag 05 maart 2014 @ 09:34:
[...]

Neem bijvoorbeeld de strpos functie. Het kan heel goed lijken dat deze gewoon keurig werkt, totdat je needle een keer aan het begin van je haystack staat.

Daarom moet je ook === gebruiken

[incaz]

RayNbow schreef op dinsdag 04 maart 2014 @ 22:36:
[...]
Natuurlijk moet je in de gaten hebben welk type een waarde van een variabele zou moeten hebben, maar een bug is zo geïntroduceerd wanneer je minder alert bent.

't Zal aan mij liggen, maar ik ben die bugs dus maar weinig tegengekomen. Gek genoeg had ik met de dynamische maar strongly typed versie van Python meer problemen dan met de implicit conversions.

[.oisyn]

!null schreef op woensdag 05 maart 2014 @ 10:17:
[...]


Daarom moet je ook === gebruiken

Dus wat heb je dan gewonnen met het typesysteem van PHP?

[!null]

Nou, er valt weinig te winnen als je het mij vraagt, haha. Wat bedoel je precies?

Als je vanuit ouderwets C komt, vind je dit soort dingen verschikkelijk. Zelfde als ik wat (oudere) collega's help met een Python scriptje en dat het indenten de structuur bepaalt. Je zou die gezichten moeten zien
(ook al zouden ze sowieso gaan indenten omdat ze nette code schrijven)
Maarja zelfs C++ met overloaden van operators bij objecten wordt ook heel snel onduidelijk, als je vanuit C redeneert. (en ik ben er ook geen fan van moet ik zeggen)

Maar we kunnen wel stellen dat niemand fan is van de loose types.

[ Voor 24% gewijzigd door !null op 05-03-2014 11:05 ]

[RayNbow]

incaz schreef op woensdag 05 maart 2014 @ 10:17:
[...]


't Zal aan mij liggen, maar ik ben die bugs dus maar weinig tegengekomen. Gek genoeg had ik met de dynamische maar strongly typed versie van Python meer problemen dan met de implicit conversions.

Maar als je code hebt als...

Python:

c = a + b

en je krijgt

TypeError: cannot concatenate 'str' and 'int' objects

dan heb je dus als programmeur een foute aanname gemaakt over de types van je variabelen. Python brengt deze foute aanname aan het licht, terwijl een systeem met weak-typing rustig doorhobbelt.

[.oisyn]

!null schreef op woensdag 05 maart 2014 @ 11:04:
Nou, er valt weinig te winnen als je het mij vraagt, haha. Wat bedoel je precies?

RayNbow suggereert dat weak typing bugs in de hand helpt. Janoz komt met een voorbeeld. Jij reageert op dat voorbeeld dat je === moet gebruiken, maar dan maak je dus geen gebruik meer van weak typing en heeft het dus nog maar weinig met het argument van RayNbow van doen.

[!null]

Op die manier. Tja Janoz gaf een probleem aan, waarvoor ik een oplossing geef. Niet dat het fantastisch is.

Dat is het ook met PHP, je kunt het zo mooi maken als je zelf wil. Maar het is een enorme vrijheid om er een enorme rotzooi van te maken. Wat helaas vaak de praktijk is.

[ Voor 6% gewijzigd door !null op 05-03-2014 11:46 ]

[RayNbow]

Heeft iemand ondertussen al een (mooie?) bugfix gevonden voor de code in RayNbow in "Wat is er mis met PHP?"?

[mrc4nl]

RayNbow schreef op woensdag 05 maart 2014 @ 11:56:
Heeft iemand ondertussen al een (mooie?) bugfix gevonden voor de code in RayNbow in "Wat is er mis met PHP?"?

Als zolderkamer programmeur zal ik er straks eens over buigen.

[NMe]

Hydra schreef op dinsdag 04 maart 2014 @ 18:28:
[...]

Van andere bekende opties, welke zijn volgens jou minder makkelijk te onderhouden en waarom?

De nadruk lag op "net zo makkelijk", niet op het "makkelijker". Voor een bekwaam programmeur is alles te onderhouden, zeker met goeie documentatie. Het is wel makkelijker om aan PHP-programmeurs te komen dan aan bijvoorbeeld Java-programmeurs en ze zijn veelal ook goedkoper, dus voor een bedrijf als geheel kan het makkelijker zijn om PHP-software te onderhouden waar dat voor de individuele programmeur niet uitmaakt.

.oisyn schreef op woensdag 05 maart 2014 @ 10:18:
[...]

Dus wat heb je dan gewonnen met het typesysteem van PHP?

Dat heeft niks met de weak typing te maken (of in elk geval héél indirect) en des te meer met de vreemde keuze om strpos een range van 0 tot x te geven en vervolgens niet net zoals de C-variant -1 te gebruiken voor failure, maar false "omdat het kan". De weak typing is geen enkel probleem in dit specifieke geval, de artistieke vrijheid met de C-library wel. Had de taal weak typing ondersteund maar de functies uit de C-library gewoon één op één overgenomen dan hadden we nu deze specifieke discussie niet.

Weak typing in combinatie met een standaardlibrary die dit gedrag vertoont nodigt trouwens wel uit tot hetzelfde gedrag in je eigen code, en dat is wel jammer.

[ Voor 11% gewijzigd door NMe op 05-03-2014 12:06 ]

[.oisyn]

RayNbow schreef op woensdag 05 maart 2014 @ 11:56:
Heeft iemand ondertussen al een (mooie?) bugfix gevonden voor de code in RayNbow in "Wat is er mis met PHP?"?

spoiler:

strcmp

[.oisyn]

NMe schreef op woensdag 05 maart 2014 @ 11:59:
Dat heeft niks met de weak typing te maken (of in elk geval héél indirect)

Zucht. Le-zen. .oisyn in "Wat is er mis met PHP?"

en des te meer met de vreemde keuze om strpos een range van 0 tot x te geven en vervolgens niet net zoals de C-variant -1 te gebruiken voor failure, maar false "omdat het kan".

Sorry maar hier vind ik niets vreemds aan. De hele reden dat C een -1 geeft is "omdat het niet anders kan". -1 is semantisch gezien gewoon een raar antwoord, het gebruik van een arbitraire int die niet in de range valt om aan te geven dat het niet gevonden is. Maar het is een workaround vanwegen het gebruikte typesystem. Bij functies als atoi() zijn de problemen nog veel groter. Liefst wil je het antwoord "niet gevonden" distantieren van "gevonden op plek N". Het gebruik van een int is begrijpelijk vanuit een C standpunt maar geniet wat mij betreft absoluut niet de voorkeur in een taal waarin je wat meer mogelijkheden tot je beschikking hebt om die distinctie te maken.

ondersteund maar de functies uit de C-library gewoon één op één overgenomen dan hadden we nu deze specifieke discussie niet.

Alleen maar omdat het specifieke voorbeeld van Janoz dan niet meer van toepassing was nee. Niet echt een steekhoudend argument imho.

[ Voor 11% gewijzigd door .oisyn op 05-03-2014 12:12 ]

[NMe]

.oisyn schreef op woensdag 05 maart 2014 @ 12:09:
[...]

Zucht. Le-zen. .oisyn in "Wat is er mis met PHP?"

Die had ik gelezen. Maar het feit dat weak typing in bepaalde situaties onhandig is neemt niet weg dat het in andere situaties juist handig kan zijn. Puur het nodig hebben van een identity-operator in een aantal gevallen maakt weak typing nog niet per definitie zinloos. In al die andere gevallen heb je er wel de voordelen van zonder over die identity na te hoeven denken.

Sorry maar hier vind ik niets vreemds aan. De hele reden dat C een -1 geeft is "omdat het niet anders kan". -1 is semantisch gezien gewoon een raar antwoord, het gebruik van een arbitraire int die niet in de range valt om aan te geven dat het niet gevonden is. Maar het is een workaround vanwegen het gebruikte typesystem. Bij functies als atoi() zijn de problemen nog veel groter. Liefst wil je het antwoord "niet gevonden" distantieren van "gevonden op plek N". Het gebruik van een int is begrijpelijk vanuit een C standpunt maar geniet wat mij betreft absoluut niet de voorkeur in een taal waarin je wat meer mogelijkheden tot je beschikking hebt om die distinctie te maken.

Strong typing valt dan weer niet echt te combineren met multiple return types, tenzij je "gekke" dingen uit gaat halen zoals bijvoorbeeld void pointers erbij betrekken. Je lijkt te zeggen dat weak typing een rare keuze is omdat je alsnog een identity nodig hebt maar vervolgens zeg je wel dat de keuze voor meerdere returntypes een logische is. Hoe zou strpos in een ideale situatie volgens jou dan moeten werken?

Alleen maar omdat het specifieke voorbeeld van Janoz dan niet meer van toepassing was nee. Niet echt een steekhoudend argument imho.

Het gaat natuurlijk niet alleen om strpos. Er zijn meer stringfuncties en spul als fopen waarvoor dit ook geldt, nog naast eventuele andere exotische functies die ik niet meteen voor de geest kan halen. Er zijn genoeg functies in de library die je "dwingen" om de weak typing van de taal even buitenspel te zetten middels de identity-operator.

[mrc4nl]

RayNbow schreef op woensdag 05 maart 2014 @ 11:56:
Heeft iemand ondertussen al een (mooie?) bugfix gevonden voor de code in RayNbow in "Wat is er mis met PHP?"?

zoiets?

PHP:

<?php
function foo($string1, $string2) {
if(strlen($string1) < strlen($string2) && strlen($string1) != strlen($string2) && is_string($string1) && is_string($string2))
{return true;}
else
{return false;}

}

[--MeAngry--]

Niet om het een of ander, maar is de === operator niet juist een essentieel onderdeel van weak typed talen? strpos lijkt mij een perfect goed voorbeeld van hoe weak typing zou moeten werken. Je zit niet vast aan 1 soort return type (boolean of int), maar je kunt er wel expliciet op controleren.

Ik werk zelf overigens de laatste tijd weer erg veel in C# na jaren bijna exclusief in PHP te hebben gewerkt, en ik moet wel zeggen dat de tekortkomingen van PHP me meer duidelijk zijn geworden. Maar geen enkele taal is heilig wat dat betreft.

[.oisyn]

NMe schreef op woensdag 05 maart 2014 @ 12:27:
[...]

Die had ik gelezen. Maar het feit dat weak typing in bepaalde situaties onhandig is neemt niet weg dat het in andere situaties juist handig kan zijn. Puur het nodig hebben van een identity-operator in een aantal gevallen maakt weak typing nog niet per definitie zinloos.

Je verwart hier strong/weak typing met static/dynamic typing. Deed ik overigens ook in mijn vorige post, waar ik zei dat C strong typed was bedoelde ik voornamelijk dat het static typed was (en ook strong maar daar ging het niet om).

PHP is dynamic en weak, het discussiepunt gaat specifiek over weak. Python is dynamic maar strong en heeft veel van de problemen van PHP dan ook niet.

Strong typing valt dan weer niet echt te combineren met multiple return types, tenzij je "gekke" dingen uit gaat halen zoals bijvoorbeeld void pointers erbij betrekken.

Het heeft niets met het hebben van meerdere return types van doen, want je wilt niet meerdere waardes geven. Je geeft 1 antwoord terug, alleen bestaat dat antwoord uit een superset van alleen ints, namelijk ook "niet gevonden". Dat is in C niet direct te modelleren (je zou een struct kunnen maken, in C++ kun je gaan voor iets als een variant<bool, int>). In menig functionele taal kan het daarentegen prima. In dynamically typed talen maakt het eigenlijk niet zoveel uit.

Je lijkt te zeggen dat weak typing een rare keuze is omdat je alsnog een identity nodig hebt

Dan interpreteer je mijn post verkeerd. De post van !null las ik meer als algemeen advies dat je === en !== moet gebruiken. Als je dat altijd doet, dan had het typesystem net zo goed niet weak kunnen zijn.

[.oisyn]

mrc4nl schreef op woensdag 05 maart 2014 @ 12:29:
[...]

zoiets?

PHP:

<?php
function foo($string1, $string2) {
if(strlen($string1) < strlen($string2) && strlen($string1) != strlen($string2) && is_string($string1) && is_string($string2))
{return true;}
else
{return false;}

}

Dus "a" is volgens jou niet kleiner dan "b"? Je tweede conditie is trouwens nutteloos, a < b impliceert a != b

[ Voor 21% gewijzigd door .oisyn op 05-03-2014 12:44 ]

[mrc4nl]

.oisyn schreef op woensdag 05 maart 2014 @ 12:42:
[...]


Dus "a" is volgens jou niet kleiner dan "b"? Je tweede conditie is trouwens nutteloos, a < b impliceert a != b

dacht dat het alleen om de lengte van de string ging
ik zal eens verder puzzelen

mijn laatste poging

PHP:

<?php
function foo($string1, $string2) {
if (is_string($string1) && is_string($string2) && strlen($string1) <= strlen($string2) && $string1 < $string2 ){
                    return true;}
else{return false;}
}
?>

let wel XX is kleiner dan AAA, of moet ik dat ook nog fixen ?

[ Voor 31% gewijzigd door mrc4nl op 05-03-2014 13:12 ]

[incaz]

RayNbow schreef op woensdag 05 maart 2014 @ 11:19:
[...]

Maar als je code hebt als...

Python:

c = a + b

en je krijgt

TypeError: cannot concatenate 'str' and 'int' objects

dan heb je dus als programmeur een foute aanname gemaakt over de types van je variabelen. Python brengt deze foute aanname aan het licht, terwijl een systeem met weak-typing rustig doorhobbelt.

Maar pas runtime, wat een beroerd moment is. Ook die fouten kunnen dus pas veel later optreden. En ze kunnen propageren: je kunt bv immers rustig een hele tijd strs concatten ipv ints optellen, en pas als je ergens een inconsistent type krijgt gaat het mis - wat het helemaal niet logisch maakt.

Doe me wat dat betreft maar in elk geval een aparte (en dus ondubbelzinnige) concat-operator die gewoon glashelder de toString-conversie aanroept.

[DXaroth]

--MeAngry-- schreef op woensdag 05 maart 2014 @ 12:30:
Niet om het een of ander, maar is de === operator niet juist een essentieel onderdeel van weak typed talen? strpos lijkt mij een perfect goed voorbeeld van hoe weak typing zou moeten werken. Je zit niet vast aan 1 soort return type (boolean of int), maar je kunt er wel expliciet op controleren.

Niet per se, zolang je operator overloading hebt... dit is een van de kleine stukjes controle die je als ontwikkelaar hoort te hebben over dingen.

php's comparison systeem is gewoon compleet onlogisch, niet duidelijk en niet consistent... maar dat sluit aan met wel meerdere dingen van php.. gebrek aan consistentie.

incaz schreef op woensdag 05 maart 2014 @ 12:50:
[...]


Maar pas runtime, wat een beroerd moment is. Ook die fouten kunnen dus pas veel later optreden. En ze kunnen propageren: je kunt bv immers rustig een hele tijd strs concatten ipv ints optellen, en pas als je ergens een inconsistent type krijgt gaat het mis - wat het helemaal niet logisch maakt.

Doe me wat dat betreft maar in elk geval een aparte (en dus ondubbelzinnige) concat-operator die gewoon glashelder de toString-conversie aanroept.

en dat is dus een fout van de programmeur, en niet van de taal. python in dit geval doet precies wat je vraagt, en zeurt precies om de goede reden.. de ontwikkelaar had hier dit van moeten maken:

Python:

c = str(a) + str(b)

of nog beter, vooraf zeuren dat de input niet klopt.

[ Voor 37% gewijzigd door DXaroth op 05-03-2014 12:54 ]

[incaz]

Ik weet niet precies wat nou het probleem is maar voor string comparisons heb je toch strcmp en evt strcasecmp als je het leuk vindt?

Ik denk dat het vooral zoveel frustratie oplevert omdat men gewoon andere dingen verwacht. Ik vind het bv heel prima om gewoon de specifieke array- of stringfunctions te gebruiken en verwacht niet dat een paar universele operators dat allemaal doen. En dus heb ik ook weinig problemen met operators als '<' op strings, omdat dat niet de manier is waarop ik het verwacht dat het werkt.

[Janoz]

!null schreef op woensdag 05 maart 2014 @ 11:45:
Op die manier. Tja Janoz gaf een probleem aan, waarvoor ik een oplossing geef. Niet dat het fantastisch is.

Dat is het ook met PHP, je kunt het zo mooi maken als je zelf wil. Maar het is een enorme vrijheid om er een enorme rotzooi van te maken. Wat helaas vaak de praktijk is.

Je geeft geen oplossing, je geeft de workaround. Het probleem dat ik weergeef is dat de makers van php in een vlaag van verstandsverbijstering bedacht hebben dat het een goed idee was om voor twee compleet verschillende situaties iets te terug te geven wat bij normaal gebruik evalueert naar exact dezelfde waarde.

In de manual staat een groot roze waarschuwingsblok om developers te wijzen op een bepaalde manier van gebruik in een verre van ongebruikelijke situatie. Dat is wat mij betreft een redelijk duidelijk signaal dat de huidige implementatie misschien niet de meest handige is.

[incaz]

DXaroth schreef op woensdag 05 maart 2014 @ 12:51:
[...]
en dat is dus een fout van de programmeur, en niet van de taal. python in dit geval doet precies wat je vraagt, en zeurt precies om de goede reden.. de ontwikkelaar had hier dit van moeten maken:

Python:

c = str(a) + str(b)

of nog beter, vooraf zeuren dat de input niet klopt.

Mooi bedacht, maar dan is if( !strpos(a,b) ) natuurlijk ook gewoon een fout van de programmeur en niet van php.

En je kunt natuurlijk niet eerst claimen dat het een groot voordeel is dat de taal iets checkt, om vervolgens de tekortkomingen af te schilderen als irrelevant en 'dat had de programmeur anders moeten doen'. Dan ben je erg naar je eigen gewenste opvatting toe aan het redeneren.

Doe mij dan maar gewoon een static strong typed.

(Wat betreft het zeuren dat de input niet klopt - dat is nou juist iets dat ik liever niet wil doen omdat het zelden nodig is. Als fouten nodig zijn, dan prima, maar be generous what you accept, of wat was het ook alweer.

En dat werkt prima: je kunt nog steeds prima onderscheid maken tussen garbage = niets van te maken, sorry, jammer dan, of 'we begrijpen prima wat je bedoelt.'
IK kom de onoverkomelijkheden van php's type conversies dus helemaal niet vaak tegen. 't Is denk ik een andere manier van benaderen.)

[Patriot]

RayNbow schreef op woensdag 05 maart 2014 @ 09:13:
[...]

Het is een nadeel van weak-typing met complexe regels. Het probleem is dat de aannames die de programmeur maakt overeen moeten komen met het gedrag van de gebruikte functies/operators.

In het kunstmatige voorbeeld hieronder (al is het niet direct een voorbeeld van weak-typing) gaat het best vaak goed (lees: de functie gedraagt zich zoals beschreven in de comments), maar de programmeur begrijpt PHP niet volledig en heeft code geschreven die niet overeenkomt met zijn aannames (en comments):

PHP:

function foo($string1, $string2) {
  /*
  Retourneert true dan en slechts dan 
  wanneer de twee argumenten strings zijn 
  en het eerste argument lexicografisch kleiner is.
  */
  return is_string($string1) && is_string($string2) && $string1 < $string2;
}

Ik laat het aan de PHPers over ter oefening om bovenstaande code te fixen.

Als eerst: Wow. Die laatste vergelijking doet mijn nekharen overeind staan

Verder zie ik niet in hoe dit een probleem is van weak-typing. Je doet een verkeerde aanname over de werking van een operator, dat kun je de taal toch niet aanrekenen?

Of vind je dat een lexicografische vergelijking dusdanig voor de hand liggend is in die situatie dat de oplossing van PHP te vergezocht is? Dat ben ik dan niet helemaal met je eens. Maargoed, dat je dat bedoelt is weer een aanname van mij. En assumptions are the motherfucker of all fuckups.

[RayNbow]

NMe schreef op woensdag 05 maart 2014 @ 12:27:

[...]

Strong typing valt dan weer niet echt te combineren met multiple return types, tenzij je "gekke" dingen uit gaat halen zoals bijvoorbeeld void pointers erbij betrekken.

Haskell kent sum-types?

mrc4nl schreef op woensdag 05 maart 2014 @ 12:47:
[...]

dacht dat het alleen om de lengte van de string ging
ik zal eens verder puzzelen

Het gaat mis bij bijv. "123" en "0124".

incaz schreef op woensdag 05 maart 2014 @ 12:50:
[...]

Maar pas runtime, wat een beroerd moment is. Ook die fouten kunnen dus pas veel later optreden. En ze kunnen propageren: je kunt bv immers rustig een hele tijd strs concatten ipv ints optellen, en pas als je ergens een inconsistent type krijgt gaat het mis - wat het helemaal niet logisch maakt.

Maar het gaat dan tenminste wel mis. Ik heb liever dat de boel eruitklapt dan dat ik een incorrect resultaat bereken. Het klopt dat de fout kan propageren.

(Het liefst heb ik static typing als het kan.)

Doe me wat dat betreft maar in elk geval een aparte (en dus ondubbelzinnige) concat-operator die gewoon glashelder de toString-conversie aanroept.

Of een awesome generieke operator als (<>) :: Monoid m => m -> m -> m, maar die wel typesafe is?

incaz schreef op woensdag 05 maart 2014 @ 13:06:
Ik weet niet precies wat nou het probleem is maar voor string comparisons heb je toch strcmp en evt strcasecmp als je het leuk vindt?

Maar het invoeren van type-specifieke functies/operators heeft dan wel weer als nadeel dat je minder gemakkelijk generieke functies kunt schrijven.

DXaroth schreef op woensdag 05 maart 2014 @ 12:51:
[...]


en dat is dus een fout van de programmeur, en niet van de taal. python in dit geval doet precies wat je vraagt, en zeurt precies om de goede reden.. de ontwikkelaar had hier dit van moeten maken:

Python:

c = str(a) + str(b)

of nog beter, vooraf zeuren dat de input niet klopt.

incaz schreef op woensdag 05 maart 2014 @ 13:17:
[...]

Mooi bedacht, maar dan is if( !strpos(a,b) ) natuurlijk ook gewoon een fout van de programmeur en niet van php.

Wat hier nou precies de fout is en wie de schuldige is, is in dit kleine simplistische voorbeeld natuurlijk moeilijk aan te wijzen. Wat als de programmeur verwachtte dat zowel a en b ints waren? Dan was misschien dit een betere oplossing geweest:

Python:

assert isinstance(a, int)
assert isinstance(b, int)
c = a + b

Op deze manier worden in ieder geval de aannames gedocumenteerd. Nogmaals, het hangt af van de situatie wat "juist" is.

Nog over if( !strpos(a,b) ). dit is deels de fout van de programmeur (uitgaande van de bedoelde betekenis if b not in a) aangezien hij het gedrag van de functie niet volledig begreep en daardoor de functie verkeerd gebruikt. Aan de andere kant is het een zwakte qua design van de library die deze functie aanbiedt. Immers, het gedrag (i.c.m. hoe de rest van PHP in elkaar steekt) is complexer dan het had kunnen zijn.

Haskell's elemIndex :: a -> [a] -> Maybe Int is dan toch een stuk mooier.

Patriot schreef op woensdag 05 maart 2014 @ 13:59:
[...]

Verder zie ik niet in hoe dit een probleem is van weak-typing. Je doet een verkeerde aanname over de werking van een operator, dat kun je de taal toch niet aanrekenen?

Zoals ik beschreef is dit voorbeeld niet direct gerelateerd aan weak-typing. Er vindt soms wel een type-conversion plaats.

Of vind je dat een lexicografische vergelijking dusdanig voor de hand liggend is in die situatie dat de oplossing van PHP te vergezocht is?

Maar < doet ook een lexicografische vergelijking voor strings, behalve wanneer beide strings alleen cijfers bevatten. Dat vind ik een vreemde keus, ja.

[.oisyn]

Patriot schreef op woensdag 05 maart 2014 @ 13:59:
Verder zie ik niet in hoe dit een probleem is van weak-typing.

Als de twee operanden die vergeleken worden een string zijn, waarom gaat hij dan proberen ze te interpreteren als getal?

Je doet een verkeerde aanname over de werking van een operator, dat kun je de taal toch niet aanrekenen?

Want het is niet de taal die de werking van de operator definieert

Of vind je dat een lexicografische vergelijking dusdanig voor de hand liggend is in die situatie dat de oplossing van PHP te vergezocht is?

A. Ja.
B. PHP vindt dat ook. "aap" < "banaan"

[RayNbow]

.oisyn schreef op woensdag 05 maart 2014 @ 14:28:
PHP vindt dat ook. "aap" < "banaan"

En zo hoort het ook. "Aap" staat vooraan op het leesplankje.

[DXaroth]

incaz schreef op woensdag 05 maart 2014 @ 13:17:
[...]


Mooi bedacht, maar dan is if( !strpos(a,b) ) natuurlijk ook gewoon een fout van de programmeur en niet van php.

Beide.

de mogelijkheden:

1) php geeft FALSE terug, de if evalueert naar true
2) php geeft 0 terug als de needle aan het begin van de haystack zit, de if evalueert naar true
3) de if evalueert naar false

Dus, als de programmeur bedoelde "doe dit als b aan het begin van a staat, of niet in a voorkomt", dan is dit een compleet juist stuk code... maar ik gok dat je er van uit gaat dat het bedoelt "doe dit als b niet in a voorkomt" .. en hierbij is waar het mis gaat.

a) de programmeur kent niet wat strpos doet
b) php's implementatie van strpos is niet consistent (een boolean terug geven als normaal een int verwacht wordt)

Er zijn wel meer eigenaardigheden in hoe PHP dingen doet:

code:

"foo" == TRUE
"foo" == 0
0 != TRUE

a == b, b == c, c != a

code:

123 == "123broodjeaap"
"123" != "123broodjeaap"

code:

"1" == " 1"
"4.2" == "4.20"
"133" == "0133"
133 != 0133
"0x10" == "16"
"1e3" == "1000"

Al met al, betekend dit dat je gewoon niet kan vertrouwen op == .. dus waarom zit het er uberhaubt in?

Vergelijkingen zijn ook niet altijd even handig; NULL < -1 en NULL == 0 .. en nog leuker: "123" < "0124"

[incaz]

RayNbow schreef op woensdag 05 maart 2014 @ 14:26:
[...]
Maar het gaat dan tenminste wel mis. Ik heb liever dat de boel eruitklapt dan dat ik een incorrect resultaat bereken. Het klopt dat de fout kan propageren.

Maar het resultaat hoeft natuurlijk niet fout te zijn. Omdat je in php concat en optellen niet kunt verwarren krijg je bij beide operators geen fout resultaat. Er hoeft dus niets uit te klappen, implicit conversions gaat daar helemaal prima.

Wat hier nou precies de fout is en wie de schuldige is, is in dit kleine simplistische voorbeeld natuurlijk moeilijk aan te wijzen. Wat als de programmeur verwachtte dat zowel a en b ints waren?

Het punt is vooral dat wat je in elk geval NIET kunt doen is zeggen dat elk falen van php om aan jouw verwachtingen te voldoen duidelijk de fout van php is, maar elk falen van Python om aan de mijne te voldoen mijn fout als programmeur is.

Maar < doet ook een lexicografische vergelijking voor strings, behalve wanneer beide strings alleen cijfers bevatten. Dat vind ik een vreemde keus, ja.

Ik vind 'm volkomen logisch eigenlijk - ik snap hoe die keuze er gekomen is EN ik was niet van plan om een lexicografische vergelijking met < te doen. Dat het kan in php vind ik dus geen enkel bezwaar - ik vind de neiging van python om een (soms behoorlijk esoterische) manier als De Juiste te verklaren en dan alle andere bruutweg te verbieden bv persoonlijk veel storender.

[MueR]

DXaroth schreef op woensdag 05 maart 2014 @ 14:44:
[...]
Dus, als de programmeur bedoelde "doe dit als b aan het begin van a staat, of niet in a voorkomt", dan is dit een compleet juist stuk code... maar ik gok dat je er van uit gaat dat het bedoelt "doe dit als b niet in a voorkomt" .. en hierbij is waar het mis gaat.

Dan zou de programmeur alsnog het uit moeten schrijven of commenten voor een ander. Als ik if (!strpos) zie, denk ik bug.

PHP:

if (strpos($a, $b) === false || strpos($a, $b) === 0)

[DXaroth]

MueR schreef op woensdag 05 maart 2014 @ 15:00:
[...]

Dan zou de programmeur alsnog het uit moeten schrijven of commenten voor een ander. Als ik if (!strpos) zie, denk ik bug.

PHP:

if (strpos($a, $b) === false || strpos($a, $b) === 0)

Helemaal mee eens.

[.oisyn]

RayNbow schreef op woensdag 05 maart 2014 @ 14:34:
[...]

En zo hoort het ook. "Aap" staat vooraan op het leesplankje.

Euh ja dat onderken ik toch? Mijn punt is dat PHP ook gewoon een lexicografische compare doet op het moment dat de strings niet interpretabel zijn als getallen. Het feit dat je dat verwacht bij de < operator is dus niet alleen niet vergezocht, zelfs PHP vindt dat dat niet vergezocht is

mrc4nl schreef op woensdag 05 maart 2014 @ 12:47:
[...]

dacht dat het alleen om de lengte van de string ging
ik zal eens verder puzzelen

mijn laatste poging

PHP:

<?php
function foo($string1, $string2) {
if (is_string($string1) && is_string($string2) && strlen($string1) <= strlen($string2) && $string1 < $string2 ){
                    return true;}
else{return false;}
}
?>

let wel XX is kleiner dan AAA, of moet ik dat ook nog fixen ?

Volgens mij snap je gewoon niet helemaal wat lexicografishe volgorde betekent . De oplossing moet je overigens gewoon zoeken in een alternatief voor de < operator. If only there existed a function that allows you to compare two strings lexographically...

[ Voor 46% gewijzigd door .oisyn op 05-03-2014 15:18 ]

[MueR]

.oisyn schreef op woensdag 05 maart 2014 @ 15:05:
If only there existed a function that allows you to complare two strings lexographically...

In PHP is dat geen uitdaging. De uitdaging is uit de manual plukken welke dat ook al weer is

[Rob]

Het is grappig dat ik vaak lees dat een programmeur een aanname doet. Een programmeur moet geen aanname doen (assumption is the mother of all screw ups) maar moet zeker weten hoe iets werkt. Hij/zij moet dus weten dat een strpos een 0 kan teruggeven en een false.

[RayNbow]

incaz schreef op woensdag 05 maart 2014 @ 14:52:
[...]

Maar het resultaat hoeft natuurlijk niet fout te zijn. Omdat je in php concat en optellen niet kunt verwarren krijg je bij beide operators geen fout resultaat. Er hoeft dus niets uit te klappen, implicit conversions gaat daar helemaal prima.

Muah, geen fout resultaat hangt natuurlijk af van de context.

PHP:

function gemiddeldeLeeftijd($a, $b) {
  return ($a + $b) / 2;
}

echo gemiddeldeLeeftijd("24", "aap");

In dit bovenstaande geval kun je de discussie aangaan wat misschien logischer is als (bedoelde) output. Is 12 de gemiddelde leeftijd of is misschien 24 beter omdat er maar 1 "valide" input is? Of moet er een foutmelding worden afgedrukt?

Je kunt niet simpelweg stellen dat een fout resultaat niet mogelijk is.

[...]

Het punt is vooral dat wat je in elk geval NIET kunt doen is zeggen dat elk falen van php om aan jouw verwachtingen te voldoen duidelijk de fout van php is, maar elk falen van Python om aan de mijne te voldoen mijn fout als programmeur is.

Uiteraard, maar ik beschreef in m'n posts dat het twee kanten opwerkt. De programmeur moet de documentatie goed lezen en de functies begrijpen en de taal/library/etc. heeft als taak om goede documentatie en gemakkelijke/begrijpbare functies/operators te leveren.^**

(** Uitgaande dat gebruiksgemak een van de doelen is van de taal.)

[...]

Ik vind 'm volkomen logisch eigenlijk - ik snap hoe die keuze er gekomen is EN ik was niet van plan om een lexicografische vergelijking met < te doen. Dat het kan in php vind ik dus geen enkel bezwaar - ik vind de neiging van python om een (soms behoorlijk esoterische) manier als De Juiste te verklaren en dan alle andere bruutweg te verbieden bv persoonlijk veel storender.

Ik snap ook wel hoe uiteindelijk dit gedrag tot stand is gekomen, maar het probleem is nu dat < lexicografische vergelijkingen kan uitvoeren voor bepaalde strings, maar niet alle. Het zijn de uitzonderingsregels die de boel complexer maken.

Daarnaast is Python zeker niet de heilige graal, maar het gebruik van < om relaties in een orde aan te geven is zeker niet esoterisch. Als je elementen in een verzameling A kunt ordenen, dan bestaat een natuurlijke manier om elementen van A* te ordenen.

.oisyn schreef op woensdag 05 maart 2014 @ 15:05:
[...]

Euh ja dat onderken ik toch?

Ik spreek je ook niet tegen. Ik gaf een extra reden waarom "aap" vooraan hoort te staan (het leesplankje als autoriteitsargument).

[_js_]

Als je PHP programmeur wordt met een C-stijl-taal-achtergrond dan moet je nog steeds de handleiding lezen en niet hopen dat de handigheidjes uit de andere taal 1 op 1 toe te passen zijn op PHP.

Dat je als C/C++ programmeur niet verwacht dat een vergelijkingsoperator meerdere soorten vergelijkingen kan doen is tot daar aan toe, maar als je het als PHP programmeur niet verwacht, dan ben je een slechte programmeur, want dit soort basale dingen staan gewoon in de handleiding.

Dat het een vreemde keuze is of lijkt kan wel zo zijn, maar volgens mij is er geen taal ter wereld die geen vreemde designkeuzes heeft gemaakt. Het archetype van een wereldvreemde implementatie van vergelijkingsoperators blijft natuurlijk C++, waar strBestandsinhoud < "string" geen vergelijking doet, maar de string toevoegt aan een outputstream en include <iostream> ook geen vergelijking maakt tussen include en iostream.

//zo, is dit topic ook weer een beetje op scherp gezet

[Rob]

Over C en vergelijkingsoperatoren gesproken. Deze kwam ik vandaag tegen op Tweakers: http://blog.existentializ...ry-of-the-gnutls-bug.html

[.oisyn]

_js_ schreef op woensdag 05 maart 2014 @ 15:40:Dat je als C/C++ programmeur niet verwacht dat een vergelijkingsoperator meerdere soorten vergelijkingen kan doen is tot daar aan toe, maar als je het als PHP programmeur niet verwacht, dan ben je een slechte programmeur, want dit soort basale dingen staan gewoon in de handleiding.

Moet ik je wormwielverhaal hier posten Janoz of doe jij het?

[BtM909]

Dude, je refereert toch niet aan een of ander verhaal wat 10 oktober 2008 is gepost he?

[mrc4nl]

.oisyn schreef op woensdag 05 maart 2014 @ 15:05:
[...]
Volgens mij snap je gewoon niet helemaal wat lexicografishe volgorde betekent .

zeg maar gerust helemaal niet

Soort van alfabetische volgorde dus
ik denk dat er een soort van while dingetje nodig is die teken voor teken analiseerd in beide strings welke er eerder is. "aarbei" is eerder dan "aap" en "0123" komt voor 012A"

[ Voor 14% gewijzigd door mrc4nl op 05-03-2014 17:09 ]

[NMe]

Strcmp is pas tig keer geroepen in dit topic...

[jbdeiman]

Volgens mij kan je de boel prima in een array gooien en er een natsort op los laten, dan kijken welke van de 2 eerder is. Maar volgens mij bedoelden jullie die functie niet?
(I know, strcmp is the one, just kidding)

Ik ben zelf vooral PHP ontwikkelaar, maar kijk nu heel erg mee in de keuken van ons ontwikkelteam aan de nieuwe applicatie en dan moet ik toch zeggen (ze ontwikkelen in C#) dat het veel praktischer leest (alleen dat al) als je vooraf opgeeft wat je gaat teruggeven en wat je verwacht. Doordat dat al duidelijk is kan je ook bepalen wat je (mogelijke) vervolgacties zijn en wat je met het geretourneerde item kan uitvoeren.

Ik heb n.a.v. daarvan mijn PHP code systematiek ook nog wat aangepast om zover mogelijk, dat typesafe te doen. Ik weet wat er terugkomt en dus ook wat ik daar voor acties mee kan uitvoeren. Gelukkig hoef ik in PHP zelf niet te sorteren, maar laat ik dat heerlijk door de database doen. Die doet dat toch veel efficiënter.

[Hydra]

DXaroth schreef op woensdag 05 maart 2014 @ 12:51:
en dat is dus een fout van de programmeur, en niet van de taal.

Gelukkig maken programmeurs nooit fouten...

[RayNbow]

NMe schreef op woensdag 05 maart 2014 @ 16:36:
Strcmp is pas tig keer geroepen in dit topic...

Of je doet dit:

PHP:

("preventcoercion" . $a) < ("preventcoercion" . $b)

[_js_]

.oisyn schreef op woensdag 05 maart 2014 @ 15:59:
[...]

Moet ik je wormwielverhaal hier posten Janoz of doe jij het?

Goed geheugen!

Maar is het echt zo vreemd om te verwachten dat "11" < "100" waar is? (De driehoek van "11", "100" en "100 apen" is wel stuk in PHP natuurlijk)

En natuurlijk lukt het piloten al honderd jaar om vliegtuigen te besturen terwijl je om sneller vooruit te gaan je de gashendel naar achter moet halen, en om rechtsaf te gaan op de taxibaan je het rechter rempedaal moet intrappen...

Of het wormwielverhaal echt opgaat of alleen een stroën man is valt dus nog te debatteren.

Edit:
Nog een mooi voorbeeld, het 1ste element van een array moet aangesproken worden als het 0e. Logisch in C/C++ vanwege het wormwiel dat er achter zit gekoppeld dat het een offset is van een pointer naar het eerste element, maar niet logisch als je gewoon het eerste element wilt. Toch zullen er mensen zijn, misschien jij zelf wel, die graag beargumenteren dat beginnen met 0 wel de juiste keuze is voor een array index.

[ Voor 24% gewijzigd door _js_ op 05-03-2014 17:09 ]

[mrc4nl]

NMe schreef op woensdag 05 maart 2014 @ 16:36:
Strcmp is pas tig keer geroepen in dit topic...

JA maar........
er moet toch een moeilijkere manier zijn te verzinnen

[RayNbow]

_js_ schreef op woensdag 05 maart 2014 @ 17:03:
Edit:
Nog een mooi voorbeeld, het 1ste element van een array moet aangesproken worden als het 0e.

EWD831

[.oisyn]

_js_ schreef op woensdag 05 maart 2014 @ 17:03:
Maar is het echt zo vreemd om te verwachten dat "11" < "100" waar is? (De driehoek van "11", "100" en "100 apen" is wel stuk in PHP natuurlijk)

Ja. Als ik een vergelijkingsoperator toepas op strings dan verwacht ik een lexicografische vergelijking. Ik ken geen enkele taal waarin dat niet zo werkt, en ja dat schept een precedent. PHP lijkt in alles op de C-familie van talen, waarom wijken ze hier dan af? Ik vind dat verwarrend. Misschien niet voor iemand die met een fris ongekneed hoofd PHP erbij pakt als zijn eerste programmeertaal, maar je weet vantevoren dat dat niet het gros van je doelgroep gaat zijn dus moet je er verdomd goed over nadenken en valide argumentatie hebben om ervan af te wijken.

Of het wormwielverhaal echt opgaat of alleen een stroën man is valt dus nog te debatteren

Wat het vooral aanstipt is dat "het is gewoon zo bedacht en gedocumenteerd" op zichzelf nog geen valide argument is.

[Patriot]

Pleuris, ik wist eerlijk gezegd niet dat PHP een lexicografische vergelijking deed in dat geval. Ik kan het in de documentatie ook nergens vinden, iemand die me daar op kan wijzen? Het enige wat ik kan vinden is dat als beide operands strings zijn ze als numeriek worden behandeld en dan zou "aap" < "banaan" naar false evalueren.

Aaargh, wat is het toch ook een schijttaal, je hebt er echt niks aan dat hij dan een lexicografische vergelijking doet.. De moeite die je moet doen om te kijken of de strings niet eventueel als nummers behandeld worden is al teveel want dan moet je gewoon strcmp doen.

En die zal dan wel weer ongeschikt zijn voor unicode.

[_js_]

.oisyn schreef op woensdag 05 maart 2014 @ 17:11:
[...]

Ja. Als ik een vergelijkingsoperator toepas op strings dan verwacht ik een lexicografische vergelijking. Ik ken geen enkele taal waarin dat niet zo werkt, en ja dat schept een precedent. PHP lijkt in alles op de C-familie van talen, waarom wijken ze hier dan af? Ik vind dat verwarrend. Misschien niet voor iemand die met een fris ongekneed hoofd PHP erbij pakt als zijn eerste programmeertaal, maar je weet vantevoren dat dat niet het gros van je doelgroep gaat zijn dus moet je er verdomd goed over nadenken en valide argumentatie hebben om ervan af te wijken.

[...]

Wat het vooral aanstipt is dat "het is gewoon zo bedacht en gedocumenteerd" op zichzelf nog geen valide argument is.

Dat is alleen zo als je al gewend bent een statische types in een andere programmeertaal. Als je een leek vraagt of 11 kleiner is dan 100 dan is dat zo, twaalf is zelfs kleiner dan honderd, of dat nou in een rekensom of in een taalzin staat.

Maar zoals eerder gezegd, alle talen hebben hun eigenaardigheden, dus je zult altijd de documentatie moeten gebruiken om met die eigenaardigheden te werken. Daarnaast is er geen publiek beschikbare reden gegeven voor waarom PHP dit ooit zo bedacht heeft, die argumentatie zou er in principe kunnen zijn.

RayNbow schreef op woensdag 05 maart 2014 @ 17:11:
[...]

EWD831

Ja, zoals ik zei, sommige mensen zullen inderdaad beargumenteren dat je vanaf 0 moet indexeren, en komen misschien zelfs met steekhoudende argumenten. Maar het wormwiel is nog steeds het meest gebruikte argument (dat ik tegenkom in discussies over waarom array indexes met 0 beginnen), en het wormwiel is de reden dat C 0 gebruikt, Edsgers argument is van decennia later dan het uitvinden van C, dus meer goedpraten/rationaliseren van wat al bestaat dan dat het uitlegt waarom een bepaalde keuze is gemaakt . Sterker nog, veel andere talen, ook moderne of goed doordachte beginnen met 1, zoals Lua, Julia en Matlab, en oude talen als COBOL en Fortran doen het ook.

Patriot schreef op woensdag 05 maart 2014 @ 17:33:
Pleuris, ik wist eerlijk gezegd niet dat PHP een lexicografische vergelijking deed in dat geval. Ik kan het in de documentatie ook nergens vinden, iemand die me daar op kan wijzen?

http://nl1.php.net/manual....operators.comparison.php , tweede tabel, eerste item. Dus echt helemaal aan het begin van de handleiding, en precies waar je het verwacht: bij de comparison operators.

[RayNbow]

Patriot schreef op woensdag 05 maart 2014 @ 17:33:
Pleuris, ik wist eerlijk gezegd niet dat PHP een lexicografische vergelijking deed in dat geval. Ik kan het in de documentatie ook nergens vinden, iemand die me daar op kan wijzen?

http://php.net/ternary, zie "Comparison with Various Types".

edit: spuit11

_js_ schreef op woensdag 05 maart 2014 @ 17:37:
Sterker nog, veel andere talen, ook moderne of goed doordachte beginnen met 1, [...] Matlab [...]

Brr... Laten we maar niet over Matlab beginnen...

[ Voor 28% gewijzigd door RayNbow op 05-03-2014 17:47 ]

[Patriot]

Ah, over die eerste rij heb ik heen gelezen. Je schiet er nog steeds geen reet mee op want alle numerieke strings zijn al numbers geworden voordat die tabel in acht wordt genomen.

De major wtfs zijn bij PHP bij mij voornamelijk op het gebied van string naar number translation geweest en dit is weer een prachtig voorbeeld. De hele lexicografische vergelijking had hier weggelaten moeten worden (omdat niet compatible met de toegepaste type juggling), of liever zouden ze strings gewoon niet naar nummers moeten translaten.

Is het niet mogelijk om PHP een fatal error te laten gooien als hij nummers probeert te maken van strings

[Hydra]

PHP zit een beetje doorspekt van "laten we dingen impliciet doen want dat is lekker handig". Nee, implicite shit is kut want het levert fouten op die je VEEL later pas opmerkt. Coldfusion heeft daar ook een handje van; mensen die een taal zo designen (als je het al zo kunt noemen) verdienen een nekschot.

[NMe]

Impliciet is niet erg, als het maar voorspelbaar is. Helaas is het dat niet of in elk geval niet altijd.

[Hydra]

NMe schreef op woensdag 05 maart 2014 @ 17:56:
Impliciet is niet erg, als het maar voorspelbaar is. Helaas is het dat niet of in elk geval niet altijd.

Nouja, het is computer software dus het is altijd "voorspelbaar" als je weet hoe het werkt. Ik ben gewoon geen voorstander van impliciete conversies. "Oh, je wil hier een nummer van maken dus dan maken we van 123abc wel gewoon 123". Neeeheee!

[_js_]

Hydra schreef op woensdag 05 maart 2014 @ 18:00:
[...]


Nouja, het is computer software dus het is altijd "voorspelbaar" als je weet hoe het werkt. Ik ben gewoon geen voorstander van impliciete conversies. "Oh, je wil hier een nummer van maken dus dan maken we van 123abc wel gewoon 123". Neeeheee!

En nu weet je waarom sommigen hun webapplicaties in assembly maken, en niet in PHP, dan verandert er namelijk niets zomaar.

//Ik hoop dat ik niet te ver ga voor de mods

[ Voor 9% gewijzigd door _js_ op 05-03-2014 18:06 ]

[Patriot]

Hydra was niet degene die claimde dat te doen hoor

Maargoed, je kunt natuurlijk rustig PHP gebruiken en kritiek hebben op bepaalde onderdelen. Je moet wel met workarounds leren leven.

edit:
tss, net stond er iets anders

[ Voor 10% gewijzigd door Patriot op 05-03-2014 18:08 ]

[Niet Henk]

PHP is geen "slechte" taal. Het is gewoon een taal met een doel.

PHP is bedacht voor web developers. Vanuit dat perspectief is het logisch om met een impliciete taal te werken, sinds goede web developers bekend zijn met JavaScript, maar soms niet met andere talen, en JavaScript is ook een impliciete taal.

Dan is het erg geschikt, omdat het "makkelijk te leren" is, en het mogelijk in een kleiner bestand resulteert omdat minder dingen uitgeschreven hoeven te worden.

Als programmeur zal je snel PHP een slechte keuze vinden, vanwege dat er zo veel dingen impliciet zijn. Maar als programmeur ben je dan ook snel bekend met andere, expliciete talen.

Om alles nog samen te vatten in een analogie:
Je kan prima biefstuk snijden met een scalpel, maar ga nooit iemand opereren met een steakmes.

[NMe]

Hydra schreef op woensdag 05 maart 2014 @ 18:00:
[...]

Nouja, het is computer software dus het is altijd "voorspelbaar" als je weet hoe het werkt.

True, al dacht ik wat meer aan het globale plaatje. Het probleem dat je met "123bla" > "123" == false hebt heeft niet zozeer met die impliciete conversie te maken maar met het feit dat je dat als programmeur niet verwacht. Een goed omkaderde impliciete conversie hoeft niet per se slecht te zijn, maar dan denk ik meer aan spul als functieargumenten. Een functie die een int verwacht maar een converteerbare string krijgt gepasst zou bijvoorbeeld gewoon kunnen werken en afhankelijk van persoonlijke voorkeur zelfs handiger kunnen zijn. In PHP kan dat verder sowieso niet werken omdat zelfs type hinten naar primitieve types niet mag.

[dylanvana]

Ik snap de hele ophef niet over

123 * 'aap' = vul maar in

Als er een mogelijkheid is dat jouw code tot deze rekensom kan leiden dan doe je zelf iets fout en niet de taal.

[Creepy]

Alleen php waarschuwt je niet voor die fout, een hoop andere omgevingen wel

[Rutix]

dylanvana schreef op woensdag 05 maart 2014 @ 18:15:
Ik snap de hele ophef niet over

123 * 'aap' = vul maar in

Als er een mogelijkheid is dat jouw code tot deze rekensom kan leiden dan doe je zelf iets fout en niet de taal.

Maar programmeurs zijn nog altijd mensen en mensen maken fouten. In een taal die strongly typed is vind je deze error al snel, in een loose typed language zul je moeten zoeken.

[NMe]

dylanvana schreef op woensdag 05 maart 2014 @ 18:15:
Ik snap de hele ophef niet over

123 * 'aap' = vul maar in

Als er een mogelijkheid is dat jouw code tot deze rekensom kan leiden dan doe je zelf iets fout en niet de taal.

Het probleem is dat er nogal eens rare input kan komen uit je database (legacy) of van je user uit. Je kan dan als programmeur het idee hebben prima code geschreven te hebben die aan je tests voldoet om er vervolgens achter te komen dat er een maffe edge case is waar je bij andere talen niet eens bij stil hoeft te staan die hier ineens roet in het eten gooit.

edit:

Spuit 11.

[_js_]

Een voorbeeld wat problemen op zou kunnen leveren, stel je hebt een webshop en verkoopt iets in verschillende maten die je uit je producteigenschappen databasetabel haalt die er uit ziet als: eigenschap (int), waarde (varchar):
"9"
"11"
"11 (extra breed)"
"100"
Als je die in PHP gaat sorteren met een eigen vergelijkingsfunctie die < gebruikt dan kun je denken dat 100 achteraan komt of dat 9 achteraan komt, maar feitelijk kunnen er nog veel meer volgordes uitkomen, of zelfs een oneindige loop afhankelijk van het sorteeralgoritme, omdat < niet transitief is, 11 (eb) is groter dan 100, en 9 is groter dan 11 (eb), maar 100 is weer groter dan 9.

D:\php>php -a -n
Interactive mode enabled

<?php
var_dump("11 (extra breed)" < "9");
bool(true)
var_dump("11 (extra breed)" < "100");
bool(false)
var_dump("9" < "100");
bool(true)

Na de eerste twee zou je dus verwachten dat de volgorde "100", "11 (eb)", "9" is, maar de laatste vergelijking zegt weer dat 100 aan het eind moet.
Numeriek vergelijken gebeurt alleen als de hele string een nummer is, bij sommige vormen van casten/conversion is dat weer anders.

[ Voor 28% gewijzigd door _js_ op 05-03-2014 18:58 ]

[NMe]

Slecht voorbeeld, omdat in dit geval juist wel numeriek gesorteerd wordt:

PHP:

var_dump('10 (extra breed)' < 100); // true

Het enige arbitraire is of 10 (extra breed) daarmee nou voor of na de normale 10 komt.

[ Voor 26% gewijzigd door NMe op 05-03-2014 18:47 ]

[_js_]

NMe schreef op woensdag 05 maart 2014 @ 18:46:
Slecht voorbeeld, omdat in dit geval juist wel numeriek gesorteerd wordt:

PHP:

var_dump('10 (extra breed)' < 100); // true

Uit een varchar databaseveld, dus al die waarden zouden strings moeten zijn. Ik zal het verduidelijken.

[NMe]

Maakt door die impliciete conversie niet uit:

PHP:

var_dump('10 (extra breed)' < '100'); // true

[DXaroth]

Niet Henk schreef op woensdag 05 maart 2014 @ 18:09:
PHP is geen "slechte" taal. Het is gewoon een taal met een doel.

PHP is bedacht voor web developers. Vanuit dat perspectief is het logisch om met een impliciete taal te werken, sinds goede web developers bekend zijn met JavaScript, maar soms niet met andere talen, en JavaScript is ook een impliciete taal.

Dan is het erg geschikt, omdat het "makkelijk te leren" is, en het mogelijk in een kleiner bestand resulteert omdat minder dingen uitgeschreven hoeven te worden.

Als programmeur zal je snel PHP een slechte keuze vinden, vanwege dat er zo veel dingen impliciet zijn. Maar als programmeur ben je dan ook snel bekend met andere, expliciete talen.

Om alles nog samen te vatten in een analogie:
Je kan prima biefstuk snijden met een scalpel, maar ga nooit iemand opereren met een steakmes.

PHP is bedacht als hobby project, en is daarna uit de hand gelopen, simpel als dat... heeft niks te maken met javascript of html of iets anders, het was een hobby project dat uit de hand is gelopen.

Dit is ook een reden van veel problemen; ze kunnen niet zo maar strpos aanpassen, want dan ben je gelijk backwards incompatible met HEEL veel zooi, en dat soort geintjes worden nooit goed opgevat door de gemeenschap er omheen.. kijk maar naar de moeizame overgang tussen python 2.7 en 3.

En qua analogie ben je op dreef, maar laat nou net de discussie zijn of php de scalpel, of het steakmes is

[NMe]

DXaroth schreef op woensdag 05 maart 2014 @ 18:51:
[...]

En qua analogie ben je op dreef, maar laat nou net de discussie zijn of php de scalpel, of het steakmes is

In die analogie is PHP eerder de spork.

[Hydra]

dylanvana schreef op woensdag 05 maart 2014 @ 18:15:
Als er een mogelijkheid is dat jouw code tot deze rekensom kan leiden dan doe je zelf iets fout en niet de taal.

Nogmaals: het is een illusie dat developers geen fouten maken. Sterker nog; het gebeurt continue. De taal is niet meer dan een tool die je moet helpen. Dynamic+weak typen is een heel vervelende manier van 'helpen': het beetje tijd dat het je scheelt geen "string" te hoeven typen verlies je meteen door lastig te vinden bug die opeens ergens anders in je code opduiken.

Dit is de reden dat grote complexe enterprise zooi over 't algemeen in statically typed talen geschreven wordt; het maakt de code in veel gevallen makkelijker te onderhouden omdat veel fouten al compile-time afgevangen worden. Die impliciete conversie van "123abc" naar 123 is nergens voor nodig; het scheelt je geen tijd, maar dat soort zaken kosten je uiteindelijk alleen maar tijd (en dus geld).

Niet Henk schreef op woensdag 05 maart 2014 @ 18:09:
PHP is geen "slechte" taal. Het is gewoon een taal met een doel.

PHP is bedacht voor web developers. Vanuit dat perspectief is het logisch om met een impliciete taal te werken, sinds goede web developers bekend zijn met JavaScript, maar soms niet met andere talen, en JavaScript is ook een impliciete taal.

Ik ben erg benieuwd hoe jij aan dit stukje geschiedenis komt. Daarnaast vind ik dat je nogal een bijzondere logische sprong maakt: "PHP is voor web DUS is het logisch dat het 'impliciet' is. Hoezo? Rare lastig te vinden bugs zijn okay als je HTML uitspuugt? Web developers zijn lui? Web developers werken in notepad i.p.v. een echte IDE? Waar komt die sprong vandaan?

Dan is het erg geschikt, omdat het "makkelijk te leren" is, en het mogelijk in een kleiner bestand resulteert omdat minder dingen uitgeschreven hoeven te worden.

En die paar bytes levert dan volgens jou performance winst op ofzo?

Als programmeur zal je snel PHP een slechte keuze vinden, vanwege dat er zo veel dingen impliciet zijn. Maar als programmeur ben je dan ook snel bekend met andere, expliciete talen.

En er zijn mensen die programmeren in PHP die geen programmeurs zijn?

Om alles nog samen te vatten in een analogie:
Je kan prima biefstuk snijden met een scalpel, maar ga nooit iemand opereren met een steakmes.

Je bedoelt neem ik aan hier dat PHP het steakmes is?

[ Voor 43% gewijzigd door Hydra op 05-03-2014 18:58 ]

[_js_]

NMe schreef op woensdag 05 maart 2014 @ 18:48:
Maakt door die impliciete conversie niet uit:

PHP:

var_dump('10 (extra breed)' < '100'); // true

Het voorbeeld aangepast, hopelijk klopt het nu met wat ik wil zeggen

[NMe]

_js_ schreef op woensdag 05 maart 2014 @ 18:55:
[...]

Het voorbeeld aangepast, hopelijk klopt het nu met wat ik wil zeggen

Nu wel ja. Overigens toont dit getennis over en weer mooi aan waarom het totaal onvoorspelbaar is wat er nu weer met je operand gebeurt en waarom dit inderdaad een behoorlijke tekortkoming is van de taal.

Overigens is er een aantal befaamde quotes die goed illustreren waarom PHP uit zo'n diep dal heeft moeten komen:
http://en.wikiquote.org/wiki/Rasmus_Lerdorf

[_js_]

NMe schreef op woensdag 05 maart 2014 @ 19:03:
[...]

Nu wel ja. Overigens toont dit getennis over en weer mooi aan waarom het totaal onvoorspelbaar is wat er nu weer met je operand gebeurt en waarom dit inderdaad een behoorlijke tekortkoming is van de taal.

Overigens is er een aantal befaamde quotes die goed illustreren waarom PHP uit zo'n diep dal heeft moeten komen:
http://en.wikiquote.org/wiki/Rasmus_Lerdorf

En de oplossing voor het probleem wat ik geschetst heb is natuurlijk dat PHP zorgt dat wanneer een string-vergelijking een verschil aantreft, hij gaat kijken of het om een nummer gaat en dan een numerieke vergelijking gaat doen. Dan is het allemaal wel weer transitief en logisch. Ik zal een bugmelding doen, of misschien beter zelf de patch schrijven.

"8 appels" < "10 peren"
"Ik heb 2 bananen" < "Ik heb 10 druiven"
"9" < "10 apen"

[ Voor 3% gewijzigd door _js_ op 05-03-2014 19:11 ]

[StM]

Helaas is Rasmus één van de grootste redenen dat PHP niet de echt grote stappen vooruit weet te zetten. Ik heb een aantal discussies met hem in het verleden gehad, maar veel verder van ik vind dat het zo hoort te zijn dus blijft het zo (new obj(func()) doet niks als er geen constructor is bv) kwam het niet. Daarnaast is een groot probleem dat Rasmus vind dat PHP zo dicht mogelijk tegen de onderliggende libs moet liggen. Hij is het dus helemaal niet eens met dat de functiebenaming inconsistent is...

[.oisyn]

_js_ schreef op woensdag 05 maart 2014 @ 17:37:
[...]

Dat is alleen zo als je al gewend bent een statische types in een andere programmeertaal.

Nonsens. Javascript en Python doen ook een lexicomp. En ik durf de aanname wel te maken dat ook Ruby dat doet.

Als je een leek vraagt of 11 kleiner is dan 100 dan is dat zo, twaalf is zelfs kleiner dan honderd, of dat nou in een rekensom of in een taalzin staat.

Vindt diezelfde leek ook dat aap kleiner is dan een banaan? Maar dat 4 apen niet kleiner is dan 3 bananen?.

[ Voor 24% gewijzigd door .oisyn op 05-03-2014 23:27 ]

[Hydra]

_js_ schreef op woensdag 05 maart 2014 @ 19:11:
"8 appels" < "10 peren"
"Ik heb 2 bananen" < "Ik heb 10 druiven"
"9" < "10 apen"

En jij vindt dat je daar dan antwoord op krijgt in plaats van een "WTF ben jij aan het doen?"-melding logisch?

[begintmeta]

offtopic:
.oisyn, zoeel ouder dan C is Fortran toch niet? (tenminste, als je naar de recentste updates kijkt, anders scheelt het toch weer 15 jaar als ik wikipedia mag geloven)

[ Voor 54% gewijzigd door begintmeta op 05-03-2014 20:14 ]

[_js_]

Hydra schreef op woensdag 05 maart 2014 @ 20:01:
[...]


En jij vindt dat je daar dan antwoord op krijgt in plaats van een "WTF ben jij aan het doen?"-melding logisch?

Er komt sowieso een antwoord op, of je nou lexografisch vergelijkt of mijn aangepaste natural sort gebruikt. Lexografische vergelijking van cijfers heeft heel weinig betekenis, ik denk nog iets minder dan gecombineerd lexografisch en numeriek, maar zoals .oisyn aangeeft apen en bananen vergelijken is niet altijd logisch. Lexografisch kan allemaal wel mooi gedefinieerd zijn en volgens ascii tabellen werken en zo voort, maar dat maakt het nog niet logisch.

.oisyn schreef op woensdag 05 maart 2014 @ 19:55:
[...]

Nonsens. Javascript en Python doen ook een lexicomp. En ik durf de aanname wel te maken dat ook Ruby dat doet.

Ze doen aan lexicomp wanneer je alleen strings gebruikt, Python doet niet/niet echt aan verschillende types vergelijken, maar in Javascript zodra je gaat wisselen tussen types heb je daar ook type coercion, dus je zou niet mogen schrikken wanneer numerieke characters in een string zomaar als getal worden vergeleken, niet in Javascript, dus ook niet PHP, PHP trekt alleen de logica van Javascript nog een stapje verder door (vast om het helemaal coherent en logisch te maken ). En ook C-stijl acties die eerder in de draad werden aangedragen als vergelijken met 0 voor een null-string gaat in Javascript niet op precies dezelfde manier werken.

Andere grote talen zoals C# doen het ook fout.
C# met .Net 4.0 en nieuwer doet stringvergelijkingen ook niet altijd goed, maar daar is het wel een bug, "won't fix" weliswaar, maar toch.

C#:

    [TestClass]
    public class CompareStringTest
    {
        private static bool isLessThan(string a, string b)
        {
            return string.Compare(a, b, StringComparison.InvariantCulture) == -1;
        }

        [TestMethod]
        public void TestOrder()
        {
            string a = "Microsoft-DotNetIsNotAbleToCompareStrings";
            string b = "MICROSOFTDOTNETISNOTABLETOCOMPARESTRINGS";
            string c = "MicrosoftDotNetIsNotAbleToCompareStrings'";

            //If a < b
            Assert.IsTrue(isLessThan(a, b), "a<b");
            //and b < c
            Assert.IsTrue(isLessThan(b, c), "b<c");
            //then  a < c fails ???????
            Assert.IsTrue(isLessThan(a, c), "a<c");
        }
    }

[incaz]

_js_ schreef op woensdag 05 maart 2014 @ 18:41:
Een voorbeeld wat problemen op zou kunnen leveren, stel je hebt een webshop en verkoopt iets in verschillende maten die je uit je producteigenschappen databasetabel haalt die er uit ziet als: eigenschap (int), waarde (varchar):

Dan denk ik: dat soort dingen laat je toch nadrukkelijk door de db sorteren (of je model ofzo), en anders op een custom sort-veld? Dat soort dingen uberhaupt doen in php voelt al tamelijk hackish. Sorteren op custom descriptions die je ook nog eens zelf samenstelt uit diverse databasevelden zou ik proberen te vermijden, oa omdat ik ook weinig zin heb dat sorteervolgorde anders zou zijn als de descriptions ooit wijzigen. Daar worden gebruikers erg ongelukkig van over het algemeen.

En dat is niet flauw bedoeld om je voorbeeld onderuit te halen, maar het blijkt dat in mijn praktijk heel veel van de potentieel moeilijke situaties helemaal niet terecht komen in de directe php, maar eerder in het model.

Maar goed - om mezelf dan ook alvast van kritiek te voorzien: daarbij vertrouw ik natuurlijk weer wel op een strong typed systeem, namelijk de db. En daar zijn per veldtype operators als SUM of ORDER wel goed gedefinieerd.

[Zoijar]

_js_ schreef op woensdag 05 maart 2014 @ 20:55:
Andere grote talen zoals C# doen het ook fout.
C# met .Net 4.0 en nieuwer doet stringvergelijkingen ook niet altijd goed, maar daar is het wel een bug, "won't fix" weliswaar, maar toch.

Als je met dingen als unicode te maken krijgt is het vrijwel onmogelijk om 'goed' te doen. Net als dat je geen uppercase() functie kan schrijven die alles goed doet. Je moet dan aangeven wat je vergelijkt. En als je C# aangeeft dat je gewoon bytes wilt vergelijken werkt het prima.

Dit heeft nog te maken met de antieke gedachte die bij veel programmeurs is vastgeroest dat characters ascii bytes zijn met een orderning.

Maar goed, elke taal die niet statitsch checked is kut imho. Simpelweg omdat je 100% coverage moet halen in je tests en dat zuigt. Ik zie ook echt geen bestaansrecht meer voor dat soort talen. Het is ook niet of ze niet dynamisch kunnen zijn; het enige is dat je even een compile/check fase doet. De enige rede dat er geen statische type checking is is omdat het moeilijk te implementeren is -- en dat wordt verkocht als "het is zo makkelijk voor de gebruikers". Bs. Ik heb er nooit iets anders dan last ondervonden als je voorbij de 'hello world' gaat.

Lua, even kijken of een table leeg is: function is_empty(x) if not next(x) then print("empty!") end end is_empty({[false] = "0"}) ... oops

[ Voor 32% gewijzigd door Zoijar op 05-03-2014 21:16 ]

[Janoz]

Rob schreef op woensdag 05 maart 2014 @ 15:38:
Het is grappig dat ik vaak lees dat een programmeur een aanname doet. Een programmeur moet geen aanname doen (assumption is the mother of all screw ups) maar moet zeker weten hoe iets werkt. Hij/zij moet dus weten dat een strpos een 0 kan teruggeven en een false.

De taal waarin je je applicatie schrijft is je gereedschap. Ik zou een stuk minder productief zijn wanneer ik bij elk wissewasje weer de documentatie in moet duiken om te lezen welke uitzondering voor dat specifieke deel weer geldt. Je verwacht een bepaalde consistentie. Een monteur krijgt ook niks meer gedaan wanneer hij telkens moet kijken of de bout die hij los moet draaien deze keer met de klok mee of tegen de klok in moet.

[Amanush]

Janoz schreef op woensdag 05 maart 2014 @ 21:05:
[...]

De taal waarin je je applicatie schrijft is je gereedschap. Ik zou een stuk minder productief zijn wanneer ik bij elk wissewasje weer de documentatie in moet duiken om te lezen welke uitzondering voor dat specifieke deel weer geldt. Je verwacht een bepaalde consistentie. Een monteur krijgt ook niks meer gedaan wanneer hij telkens moet kijken of de bout die hij los moet draaien deze keer met de klok mee of tegen de klok in moet.

Ondaks dat ik een moderator quote, ben ik het met je eens. Programmeertalen horen dingen consequent te doen. Denk aan function-benamingen, function-argumenten en noem maar op!

[_js_]

incaz schreef op woensdag 05 maart 2014 @ 20:59:
[...]


Dan denk ik: dat soort dingen laat je toch nadrukkelijk door de db sorteren (of je model ofzo), en anders op een custom sort-veld? Dat soort dingen uberhaupt doen in php voelt al tamelijk hackish. Sorteren op custom descriptions die je ook nog eens zelf samenstelt uit diverse databasevelden zou ik proberen te vermijden, oa omdat ik ook weinig zin heb dat sorteervolgorde anders zou zijn als de descriptions ooit wijzigen. Daar worden gebruikers erg ongelukkig van over het algemeen.

En dat is niet flauw bedoeld om je voorbeeld onderuit te halen, maar het blijkt dat in mijn praktijk heel veel van de potentieel moeilijke situaties helemaal niet terecht komen in de directe php, maar eerder in het model.

Maar goed - om mezelf dan ook alvast van kritiek te voorzien: daarbij vertrouw ik natuurlijk weer wel op een strong typed systeem, namelijk de db. En daar zijn per veldtype operators als SUM of ORDER wel goed gedefinieerd.

In de praktijk kijkt natuurlijk geen mens naar de producteigenschappen, alleen klanten. Jij haalt ze direct uit de database van de leverancier of fabrikant. Als er wel een mens naar kijkt dan is het moeten gebruiken van een aparte sorteerveld niet gebruikersvriendelijk, want dat betekent een hoop extra handelingen en tijd om het goed te krijgen. En omdat ORDER BY lexografisch sorteert bij mijn voorbeeld, 2 na 11 dus, is dat niet handig. Logisch dat je dus je sortering voor het in de database gooien of na het eruit halen door PHP laat doen, en dan kun je dus wel makkelijk een fout maken met het gebruiken < of >. Lijkt mij eerlijk gezegd niet heel ver van de praktijk liggen.

[incaz]

Amanush schreef op woensdag 05 maart 2014 @ 21:08: Programmeertalen horen dingen consequent te doen. Denk aan function-benamingen, function-argumenten en noem maar op!

Ik heb nog nooit een taal met consistente function-benamingen of function-argumenten gezien, het is volgens mij een illusie dat dat uberhaupt mogelijk is. Gewoon - omdat menselijke taal niet op die manier consistent is en programmeertalen altijd een brug zijn tussen menselijke taal en computer.

_js_ schreef op woensdag 05 maart 2014 @ 21:14:
[...]
In de praktijk kijkt natuurlijk geen mens naar de producteigenschappen, alleen klanten. Jij haalt ze direct uit de database van de leverancier of fabrikant.

Dat zou kunnen. Maar in dat geval zou ik nog steeds niet de sortfunctie het probleem laten oplossen, maar de inleesfunctie, zodat de info op de juiste manier in de db staat.
En zou er echt hogere magie nodig zijn, met zeer gewikkelde splits ofzo, dan zou ik dus niet vertrouwen op een simpele <-operator, dat zijn nou juist precies de situaties waarvan ik al vooraf weet dat ik we expliciet moet maken wat ik met welke params doe en hoe.

[NMe]

incaz schreef op woensdag 05 maart 2014 @ 21:57:
[...]

Ik heb nog nooit een taal met consistente function-benamingen of function-argumenten gezien, het is volgens mij een illusie dat dat uberhaupt mogelijk is. Gewoon - omdat menselijke taal niet op die manier consistent is en programmeertalen altijd een brug zijn tussen menselijke taal en computer.

Ik kan me op dat vlak in .NET en Java eigenlijk geen gekke dingen voor de geest halen?

[kenneth]

Het enige waar ik zo gauw op kom is dat in .NET 31-12-2013 week 53 is en 1-1-2014 week 1.

En dan is er wel goed gedocumenteerd dat ze in dit geval afwijken van iso-8601 maar beter documenteer je niets en wijk je gewoon niet af

[Caelorum]

NMe schreef op woensdag 05 maart 2014 @ 22:11:
[...]
Ik kan me op dat vlak in .NET en Java eigenlijk geen gekke dingen voor de geest halen?

Als je diep genoeg gaat zoeken zal je wel wat archaïsche .net 1.0 classes en functies tegenkomen die wat raar zijn vergeleken met de nieuwere functies.

[Gomez12]

_js_ schreef op woensdag 05 maart 2014 @ 21:14:
[...]

In de praktijk kijkt natuurlijk geen mens naar de producteigenschappen, alleen klanten. Jij haalt ze direct uit de database van de leverancier of fabrikant. Als er wel een mens naar kijkt dan is het moeten gebruiken van een aparte sorteerveld niet gebruikersvriendelijk, want dat betekent een hoop extra handelingen en tijd om het goed te krijgen. En omdat ORDER BY lexografisch sorteert bij mijn voorbeeld, 2 na 11 dus, is dat niet handig. Logisch dat je dus je sortering voor het in de database gooien of na het eruit halen door PHP laat doen, en dan kun je dus wel makkelijk een fout maken met het gebruiken < of >. Lijkt mij eerlijk gezegd niet heel ver van de praktijk liggen.

Wat ik veel logischer vind is om gewoon in de database een eigenschap een type te geven en dan met behulp van dat type te sorteren, dan kan ik type numeriek gewoon laten sorteren door de db, dan kan ik gewoon custom sortering in de db proppen en door de db laten afhandelen.

Ik werk met een database met een boel product eigenschappen en als je kledingmaten maar ook kleuren wilt gaan sorteren dan wil je echt niet dat soort dingen in PHP gaan sorteren.

Als jij potten verf met 100.000'en kleuren moet presenteren (je kent die verfmengers bij Gamma toch wel?) dan wil ik niet eerst 100.000 records uit de db moeten halen om deze in php te laten sorteren om ze daarna te gaan pagineren en bij pagina 2 hetzelfde geintje te moeten doen.
Of kleding die in 10 maten en 40 kleuren te krijgen is en dan ook nog eens in een jongens/meisjes/heren/dames versie te krijgen is.

Oftewel in mijn wereld wil je absoluut niet in php gaan sorteren dan moet de dbase gewoon de data gesorteerd en gepagineerd afleveren, anders is gewoon je hele performance ruk.

Ik heb zelf zoiets van : Als je de aantallen hebt dat je het in php kan sorteren (dbase/tabulaire data dan) dan kan je het net zo goed in JS laten sorteren zodat je met een beetje extra moeite de klant zelf kan laten sorteren naast de initiele sortering

[.oisyn]

Amanush schreef op woensdag 05 maart 2014 @ 21:08:
[...]

Ondaks dat ik een moderator quote, ben ik het met je eens.

Want met moderators moet je het niet eens zijn

[drm]

Gomez12, misschien moeten we het dan over de quirks van MySQL gaan hebben

[Gomez12]

.oisyn schreef op woensdag 05 maart 2014 @ 23:31:
[...]

Want met moderators moet je het niet eens zijn

If yes then agree with mod to disagree with mods.

does not compute

drm schreef op woensdag 05 maart 2014 @ 23:32:
Gomez12, misschien moeten we het dan over de quirks van MySQL gaan hebben

Ik had het toch over dbases niet over MySQL (Start the flamewar)

[.oisyn]

_js_ schreef op woensdag 05 maart 2014 @ 20:55:
Ze doen aan lexicomp wanneer je alleen strings gebruikt

Exactly, want dan is het niet ambigu wat je wilt

maar in Javascript zodra je gaat wisselen tussen types heb je daar ook type coercion, dus je zou niet mogen schrikken wanneer numerieke characters in een string zomaar als getal worden vergeleken, niet in Javascript, dus ook niet PHP

Ik snap niet waarom je daarom zou schrikken. Met een string kun je een getal representeren, dus is het niet heel vreemd om de string ook te interpreteren als getal als je 'm vergelijkt met een ander getal. Zolang dat kan in ieder geval, en dat is weer iets waar php de mist in gaat, itt javascript.

PHP trekt alleen de logica van Javascript nog een stapje verder door

Wat compleet arbitrair is. Wie zegt dat die reeks cijfers in de string daadwerkelijk een getal representeren en geen datum, bankrekening of telefoonnummer? PHP kan die aanname helemaal niet maken, maar doet het wel. Van hetzelfde niveau als de aanname dat input wel de database in moet dus we gaan het lekker standaard escapen.

[ Voor 5% gewijzigd door .oisyn op 05-03-2014 23:41 ]

[Amanush]

.oisyn schreef op woensdag 05 maart 2014 @ 23:31:
[...]

Want met moderators moet je het niet eens zijn

Je komt in de buurt…

[Rutix]

Amanush schreef op donderdag 06 maart 2014 @ 06:45:
[...]

Je komt in de buurt…

En dan vind je het gek dat je niet serieus genomen word.

.oisyn schreef op woensdag 05 maart 2014 @ 23:39:
[...]

Wat compleet arbitrair is. Wie zegt dat die reeks cijfers in de string daadwerkelijk een getal representeren en geen datum, bankrekening of telefoonnummer? PHP kan die aanname helemaal niet maken, maar doet het wel. Van hetzelfde niveau als de aanname dat input wel de database in moet dus we gaan het lekker standaard escapen.

Precies. Hiervoor zei iemand dat programmeurs geen aannames mogen maken (wat natuurlijk onmogelijk is want je kunt niet alles weten) maar ik vind dat talen dat sowieso niet mogen doen en precies om de reden die .oisyn aangeeft.

[BtM909]

Amanush schreef op donderdag 06 maart 2014 @ 06:45:
[...]

Je komt in de buurt…

En aangezien het niet ontopic is, dan hou je die discussie maar buiten dit topic

Feedback kan en hoort nog steeds in Feedback op moderatie binnen de Devschuur

[Barryvdh]

[..] Van hetzelfde niveau als de aanname dat input wel de database in moet dus we gaan het lekker standaard escapen.

magic_quotes is al sinds 5.3 deprecated (bijna 5 jaar) en sinds 5.4 ook verwijderd.

[.oisyn]

Volgens mij is iedereen hier daar wel van op de hoogte. Verandert dat iets aan mijn punt?

[Barryvdh]

.oisyn schreef op donderdag 06 maart 2014 @ 11:23:
Volgens mij is iedereen hier daar wel van op de hoogte. Verandert dat iets aan mijn punt?

Dan is dat nu toch niet meer relevant?

[.oisyn]

Ik zeg dat het van hetzelfde niveau is, niet dat het nu nog relevant is.