PHP als loose typed taal

Modbreak:

Dit topic is afgesplitst naar aanleiding van TRRoads in "[Alg] Slechtste programmeervoorbeelden d...".

quote:

TRRoads schreef op zondag 24 augustus 2008 @ 23:55:
PHP documentatie is nooit echt iets geweest om over naar huis te schrijven en dat is eigenlijk alleen maar erger geworden.

Je kunt dat woordje "documentatie" in je laatste zin ook wel weghalen

Een moderator wijzigde dit bericht 26-08-2008 04:33 (79%)

Ha ha ha.

Noujah dat zeggen sommige mensen ook over Mac, of over Linux op de desktop, toch gebruiken veel mensen het dus they must be doing something right.

Sorry hoor, maar heb je het nu over de documentatie of over de reacties op de documentatie .oisyn? Ik zie sowieso niet helemaal in wat er mis is met de documentatie van PHP. Dat deze op bepaalde punten verbeterd kan/moet worden is een tweede, maar zo slecht is het nu ook weer niet.

.oisyn zegt dat PHP ook slecht is, ik zeg dus dat sommige mensen dat ook over andere dingen zeggen maar het uiteindelijk toch succesvol is.

De documentatie van PHP is IMHO vrij slecht, veel nieuwe features staan er niet in of gewoon erg slecht.
De voorbeelden zitten vol met bad practices. Sinds ze over zijn gegaan naar die nieuwe structuur zijn veel dingen compleet onvindbaar totdat je weet waar je moet zoeken.

Er is geen overall structuur, het is meer een naslagwerk, als je niet precies weet wat je zoekt vind je nooit iets terug.

Een van de ergste punten is nog wel dat de documentatie alleen geldig is voor de nieuwe release versie van PHP (met uitzonderingen voor vaak lege pagina's van de nightly build) maar dit is nergens echt aangegeven.
Wijzigingen in de werking kunnen dus erg verwarrend zijn omdat jouw PHP wellicht niet doet wat de handleiding zegt dat ie moet doen.

quote:

TRRoads schreef op maandag 25 augustus 2008 @ 01:04:
.oisyn zegt dat PHP ook slecht is, ik zeg dus dat sommige mensen dat ook over andere dingen zeggen maar het uiteindelijk toch succesvol is.

Echter maakt succesvol het niet meteen goed. En dat het niet goed is leidt ook tot het volgende punt:

quote:

Wijzigingen in de werking kunnen dus erg verwarrend zijn omdat jouw PHP wellicht niet doet wat de handleiding zegt dat ie moet doen

Over heel veel dingen in PHP wordt niet nagedacht. Veel neven-effecten van veel functies laten zich leiden door hoe de code geschreven is, ipv dat die neven-effecten van tevoren goed worden uitgedacht / gedocumenteerd en dat men de code daar dus ook op ontwerpt. Het gevolg hiervan is dat een wijziging in de implementatie van een functie ineens gevolgen gaat hebben voor de inmiddels gedocumenteerde bijwerkingen.

Een goed voorbeeld hiervan was geloof ik een bug-report van het feit dat een willekeurige niet-integer string altijd true comparet met int of float 0. De bug werd gewaved met de mededeling dat dat geen bug was omdat PHP de string eerst cast naar een int of float, wat 0 oplevert bij ongeldige strings. Wat ze dus feitelijk zeggen is dat het geen bug is omdat de code nou eenmaal zo is opgeschreven. Maar als je die redenatie aanhoudt dan bestaan er geen bugs meer

@iosyn
dat php de RNG seed met de pid en de microtijd is inderdaad niet sterk maar php gebruikt volgensmij de mersenne twister wat toch best een sterk algorithme is en zich immidels wel heeft bewezen. maar inderdaad elke RNG is zo sterk als zijn seed. maar /dev/random op elke hit openen heeft ook duidelijk zijn nadelen en kan je zelf ook makelijk implementeren maar niet echt cross-platform he.

de PHP documentatie kun je inderdaad beter een naslag werk noemen welke toch best compleet is. het is wel een gemis dat je niet per versie kunt filteren want hoeveel webhost draaien de laaste versie van PHP. vele zitten nog in PHP4 terwijl PHP5 een stap in de goede richting is.

PHP heeft zeker zijn zwake kanten maar als je kijk naar de geschieden en hoe PHP onstaan is wordt het een steeds profesionellere programmeer taal. vergelijkbaar met hoe Linux zich heeft ontwikkeld. PHP's grooste probleem is dat ze backward compatible willen zijn en daarom dus ook slechte keuzes uit het verleden vandaag nog steeds moeten dragen. PHP6 zou een echt breekpunt met het verleden moeten zijn. maar ik ga hier niet de PHP vs C/C++/C# vs Java discussie voeren.

de 'bug' die jij noemt is inderdaad geen bug maar een gevolg van dat PHP loose-typed is. veel loose-typed programmeer talen zullen precies het zelfde resultaat geven. je kunt een string niet direct vergelijken met een int of float dus casten is noodzaak. en als de string geen numerieke waarde beschrijft is de enige logische waarde die je er aan kunt geven 0 wat eigenlijk zo iets betekent als 'deze string kan ik niet lezen als een nummer'. en 0 == 0 is inderdaad true. pas wanneer een geldige string zoals '43' niet zou casten naar integer 43 zou er een bug zijn want '43' == 43 is true in loose-typed programmeer talen. dat is nou de eigenschap van een loose-typed programmer taal welke PHP is.

daarom is er ook de === operator welke naast de waarde ook het type vergelijkt en '43' === 43 geeft dan ook false. een andere vraag is waarom iemand '0' == 0 zou willen vergelijken. niet echt zinvol he.

quote:

TRRoads schreef op maandag 25 augustus 2008 @ 01:04:
.oisyn zegt dat PHP ook slecht is, ik zeg dus dat sommige mensen dat ook over andere dingen zeggen maar het uiteindelijk toch succesvol is.

De documentatie van PHP is IMHO vrij slecht, veel nieuwe features staan er niet in of gewoon erg slecht.
De voorbeelden zitten vol met bad practices. Sinds ze over zijn gegaan naar die nieuwe structuur zijn veel dingen compleet onvindbaar totdat je weet waar je moet zoeken.

Er is geen overall structuur, het is meer een naslagwerk, als je niet precies weet wat je zoekt vind je nooit iets terug.

Een van de ergste punten is nog wel dat de documentatie alleen geldig is voor de nieuwe release versie van PHP (met uitzonderingen voor vaak lege pagina's van de nightly build) maar dit is nergens echt aangegeven.
Wijzigingen in de werking kunnen dus erg verwarrend zijn omdat jouw PHP wellicht niet doet wat de handleiding zegt dat ie moet doen.

Daar heb je inderdaad een aantal hele sterke punten. Ik geef toe dat het inderdaad meer een naslagwerk is. Het hangt ook wel af van je ervaring met de documentatie (ik blijf het voor het gemak toch zo noemen ), want ik kan er uitstekend mee uit de voeten.

@.oiysin:
PHP gaat in die zin wel de goede kant op. Vooral het behouden van backwardscompatibiliteit is het probleem. En tsja, zoals al eerder gezegd is jouw "bug" natuurlijk vrij logisch te verklaren bij een loose-typed taal. Het is gewoonweg geen bug.

quote:

Patriot schreef op maandag 25 augustus 2008 @ 08:56:
PHP gaat in die zin wel de goede kant op. Vooral het behouden van backwardscompatibiliteit is het probleem. En tsja, zoals al eerder gezegd is jouw "bug" natuurlijk vrij logisch te verklaren bij een loose-typed taal. Het is gewoonweg geen bug.

En daar doe je nu precies wat .oisyn de PHP ontwikkelaars verwijt. Het gedrag is verklaarbaar (al het gedrag van de computer is verklaarbaar aangezien het een exact logisch apparaat is), maar dat praat de bug nog niet goed. Zolang dit nog steeds de manier is waarop ze daar met bugreports om gaan kun je onmogelijk spreken van een professionele aanpak.

* Janoz heeft ff lopen zoeken en kwam inderdaad deze nog tegen : [PHP] Array met foreach() wijzigen .... It's not a bug, it's a feature....

Janoz wijzigde dit bericht 25-08-2008 09:12 (5%)

quote:

Janoz schreef op maandag 25 augustus 2008 @ 09:11:
[...]

En daar doe je nu precies wat .oisyn de PHP ontwikkelaars verwijt. Het gedrag is verklaarbaar (al het gedrag van de computer is verklaarbaar aangezien het een exact logisch apparaat is), maar dat praat de bug nog niet goed. Zolang dit nog steeds de manier is waarop ze daar met bugreports om gaan kun je onmogelijk spreken van een professionele aanpak.

Het is geen bug! Waarom is het überhaupt fout? Omdat het in andere talen anders gaat? Als je een string vergelijkt met 0 en die string bevat tekens anders dan cijfers dan is dat jouw fout, niet wat PHP er vervolgens van tracht te maken.

quote:

* Janoz heeft ff lopen zoeken en kwam inderdaad deze nog tegen : [PHP] Array met foreach() wijzigen .... It's not a bug, it's a feature....

Ook dit gedrag is te verklaren, hoewel het in deze handiger zou zijn als de reference alleen bestaat in de scope van de foreach.

quote:

Patriot schreef op maandag 25 augustus 2008 @ 09:18:
[...]


Het is geen bug! Waarom is het überhaupt fout? Omdat het in andere talen anders gaat? Als je een string vergelijkt met 0 en die string bevat tekens anders dan cijfers dan is dat jouw fout, niet wat PHP er vervolgens van tracht te maken.

Dat het gedrag exact te verklaren is is niet meer dan logisch voor software. Dat kun je uiteindelijk namelijk met elke bug (muv hardware falen). Het is een bug omdat 0 == "blaat" nu eenmaal naar false zou moeten evalueren.

quote:

Ook dit gedrag is te verklaren, hoewel het in deze handiger zou zijn als de reference alleen bestaat in de scope van de foreach.

Ik raad je aan om de post van .oisyn nog even goed door te lezen.

quote:

Docey schreef op maandag 25 augustus 2008 @ 04:48:
de 'bug' die jij noemt is inderdaad geen bug maar een gevolg van dat PHP loose-typed is. veel loose-typed programmeer talen zullen precies het zelfde resultaat geven. je kunt een string niet direct vergelijken met een int of float dus casten is noodzaak. en als de string geen numerieke waarde beschrijft is de enige logische waarde die je er aan kunt geven 0 wat eigenlijk zo iets betekent als 'deze string kan ik niet lezen als een nummer'. en 0 == 0 is inderdaad true. pas wanneer een geldige string zoals '43' niet zou casten naar integer 43 zou er een bug zijn want '43' == 43 is true in loose-typed programmeer talen. dat is nou de eigenschap van een loose-typed programmer taal welke PHP is.

Vaag. Je zou dan toch denken dat de impliciete cast de enige geldige conversie gebruikt, namelijk de integer 0 casten naar de string "0".

quote:

Janoz schreef op maandag 25 augustus 2008 @ 09:38:
[...]


Dat het gedrag exact te verklaren is is niet meer dan logisch voor software. Dat kun je uiteindelijk namelijk met elke bug (muv hardware falen). Het is een bug omdat 0 == "blaat" nu eenmaal naar false zou moeten evalueren.

Waarom moet dat naar false evalueren? Dat is toch gewoon het gedrag van een loose-typed taal? Ik snap wel dat het niet hetzelfde is, maar je levert gewoon wat in als de taal loose-typed is. Dat het in strictere talen wel naar false zou evalueren maakt het toch niet een fout van PHP?

EDIT: Wat ik dus eigenlijk wil zeggen: Waarom is het een bug, en waarom is het fout, als het door de ontwikkelaars zo bedoeld is? Ze weten er gerust van, en hadden het allang kunnen veranderen als zij dit zo zouden willen. Dat is niet het geval, dus is het gewoon de manier waarop PHP werkt.

quote:

[...]


Ik raad je aan om de post van .oisyn nog even goed door te lezen.

Ok, na het lezen van een reactie door iemand van PHP op de bugreport in deze kwestie, besef ik dat het wellicht gevaarlijker kan zijn dan ik dacht. En daarom zeg ik ook, het zou niet gek zijn als de ref automatisch verdwijnt na het eindigen van de loop.

Patriot wijzigde dit bericht 25-08-2008 10:09 (13%)

Tsja, het is als PHP'er handig om te weten dat de == operator niet symmetrisch is en aan casten doet van het type links van de operator naar het type rechts van de operator. Daarmee zijn alle effecten prima te verklaren. Het is dan ook geen bug, maar gewoon het gedrag dat is gekozen wanneer verschillende types worden vergeleken.

Als je graag 'blaat' == 0 naar false wilt laten evalueren dan heb je simpelweg de verkeerde operator te pakken, en moet je === nemen

Wel kan je natuurlijk stellen dat het een onhandige keuze is geweest om een operator == in PHP een andere betekenis te geven dan in vrijwel elke andere taal.

eamelink: PHP zal met een integer en string vergelijking altijd de string naar een integer omzetten (casten wil ik het niet eens noemen, "30 appels" wordt 30 namelijk...). Dat heeft niks met het links of rechts staan te maken.
PHP:

1 2 3 4 5 6 7 8 9 10 11 12

<?php if ("test" == 0) {         echo "test = 0\n"; } if (0 == "test") {         echo "0 = test\n"; } ?>

Geeft:
test = 0
0 = test

Als het de integer had gecast naar een string omdat de string rechts in de vergelijking staat dan was de test "0" == "test" geweest wat false had opgeleverd.

Creepy wijzigde dit bericht 25-08-2008 10:18 (6%)

Pfff, hoe de == operator werkt is gewoon gedefinieerd. Het is enkel de definitie die jullie niet aanstaat.

Dit voorbeeld wordt er maar wat vaak bijgetrokken, maar als je weet wat je aan het doen bent en je code uberhaupt ergens opslaat, zal je nooit integers met een willekeurige string vergelijken. Maar goed, PHP bashen is leuk, zelfs al moet je (in dit geval) gekunstelde voorbeelden gebruiken.

@Creepy, ohhhhhh Nouja, ik gebruik nooit impliciete casts in PHP

Maakt voor de redenatie niet zoveel uit; er moet een oplossing gekozen worden voor het vergelijken van variabelen van een verschillend type, en welke keuze je ook maakt, het is geen bug.

quote:

Voutloos schreef op maandag 25 augustus 2008 @ 10:55:
Pfff, hoe de == operator werkt is gewoon gedefinieerd. Het is enkel de definitie die jullie niet aanstaat.

Beter nog, hoe PHP omgaat met het omzetten ("type juggling") van variabelen voor operators is gedefinieerd: http://nl2.php.net/language.types.type-juggling

quote:

Voutloos schreef op maandag 25 augustus 2008 @ 10:55:
Pfff, hoe de == operator werkt is gewoon gedefinieerd. Het is enkel de definitie die jullie niet aanstaat.

Dit voorbeeld wordt er maar wat vaak bijgetrokken, maar als je weet wat je aan het doen bent en je code uberhaupt ergens opslaat, zal je nooit integers met een willekeurige string vergelijken. Maar goed, PHP bashen is leuk, zelfs al moet je (in dit geval) gekunstelde voorbeelden gebruiken.

QFT.

Het lijkt tegenwoordig steeds leuker te worden om PHP te bashen. Vaak gebeurt dit om dingen die anders gedaan worden dan bij de hogere programmeertalen.

quote:

Wel kan je natuurlijk stellen dat het een onhandige keuze is geweest om een operator == in PHP een andere betekenis te geven dan in vrijwel elke andere taal.

Mja, dat heeft in principe niet zoveel te maken met de operator, meer met het feit dat de taal loose-typed is. Maar ik snap wat je bedoelt, en dit kan inderdaad lastig zijn voor iemand die eerder werkte met andere programmeertalen om zich vervolgens in PHP te verdiepen.

quote:

Docey schreef op maandag 25 augustus 2008 @ 04:48:
de 'bug' die jij noemt is inderdaad geen bug maar een gevolg van dat PHP loose-typed is

Nee, het is een gevolg van het feit dat de mensen bij Zend een stel eikels zijn

quote:

veel loose-typed programmeer talen zullen precies het zelfde resultaat geven. je kunt een string niet direct vergelijken met een int of float dus casten is noodzaak. en als de string geen numerieke waarde beschrijft is de enige logische waarde die je er aan kunt geven 0 wat eigenlijk zo iets betekent als 'deze string kan ik niet lezen als een nummer'. en 0 == 0 is inderdaad true. pas wanneer een geldige string zoals '43' niet zou casten naar integer 43 zou er een bug zijn want '43' == 43 is true in loose-typed programmeer talen. dat is nou de eigenschap van een loose-typed programmer taal welke PHP is.

Onzin. Het gedrag van PHP is niet inherent aan het feit dat het loosely typed is. Dat is bijv. Javascript ook, toch geeft die false als je een int met een string vergelijkt en de string is niet castbaar naar int, terwijl het true geeft als het wel castbaar is én de int-vergelijking geeft true. Natuurlijk moet je casten om de vergelijking te doen. Maar als de cast niet kan impliceert dat dat de twee objecten ongelijk zijn aan elkaar. Wat PHP doet is simpelweg een arbitraire waarde (0) nemen als een string niet castbaar is naar int. De situatie was imho niet anders geweest als ze bijv. 1337 als die arbitraire waarde hadden gekozen. Maar dan is iedereen het er ineens over eens dat het een complete absurditeit is.

quote:

daarom is er ook de === operator welke naast de waarde ook het type vergelijkt en '43' === 43 geeft dan ook false. een andere vraag is waarom iemand '0' == 0 zou willen vergelijken. niet echt zinvol he.

Waarom is '0' == 0 niet zinvol maar '1' == 1 wel?

quote:

Voutloos schreef op maandag 25 augustus 2008 @ 10:55:
Pfff, hoe de == operator werkt is gewoon gedefinieerd. Het is enkel de definitie die jullie niet aanstaat.

Zucht. Anders lees je mijn eerste reactie hierover nog eens door. De definitie staat mij idd niet aan, maar het was slechts een voorbeeld. Waar het om gaat is hoe die definitie tot stand is gekomen, waarom het zo is gedefinieerd. Omdat dat toevallig de bijwerking was van hoe de code is opgeschreven, of omdat ze er goed over hebben nagedacht? Gezien de overall design van PHP zet ik mijn geld in op dat eerste. En dat was nou juist de aanleiding van deze discussie.

quote:

Patriot schreef op maandag 25 augustus 2008 @ 11:53:
Het lijkt tegenwoordig steeds leuker te worden om PHP te bashen. Vaak gebeurt dit om dingen die anders gedaan worden dan bij de hogere programmeertalen.

Allereerst klopt je opmerking over "hogere programmeertalen" niet. PHP is gewoon 3GL, net als C++ en Java e.d. dat zijn. Maar even los daarvan, als wat jij zegt waar zou zijn, waarom wordt er dan zo weinig gebashed op andere talen die anders zijn? Zoals bijv. javascript?

Natuurlijk zijn er veel napraters, maar dat neemt niet weg dat er weldegelijk wat te bashen valt met valide argumenten. Het feit dat dat populair zou zijn doet daar verder niets aan af. "Oh, shit, nu is het populair, nu kan het niet meer" . Face it, PHP is gewoon voortgekomen uit een knullig hobbyprojectje. Het mist een degelijke definitie, en dat zie je terug in de eigenaardigheden in de taal. En natuurlijk, it gets the job done, maar dat is niet wat ik aan de kaak stel .

quote:

Mja, dat heeft in principe niet zoveel te maken met de operator, meer met het feit dat de taal loose-typed is.

Niet dus, zie boven.

.oisyn wijzigde dit bericht 25-08-2008 13:12 (33%)

quote:

Patriot schreef op maandag 25 augustus 2008 @ 11:53:
Het lijkt tegenwoordig steeds leuker te worden om PHP te bashen. Vaak gebeurt dit om dingen die anders gedaan worden dan bij de hogere programmeertalen.

PHP is geen lagere GL dan een andere taal (waar jij op doelt); PHP is net zo 3GL als (bijv.) C#. If anything, dan is PHP zelfs een hogere GL

RobIII wijzigde dit bericht 25-08-2008 13:01 (6%)

quote:

.oisyn schreef op maandag 25 augustus 2008 @ 12:47:
[...]

Nee, het is een gevolg van het feit dat de mensen bij Zend een stel eikels zijn

Het is zeker een gevolg van. Als de taal niet loose-typed was, dan hadden we deze discussie niet.

quote:

[...]

Onzin. Het gedrag van PHP is niet inherent aan het feit dat het loosely typed is. Dat zijn bijv. Javascript en Python ook, toch geven zij beide false als je een int met een string vergelijkt en de string is niet castbaar naar int, terwijl ze true geven als het wel castbaar is én de int-vergelijking geeft true. Natuurlijk moet je casten om de vergelijking te doen. Maar als de cast niet kan impliceert dat dat de twee objecten ongelijk zijn aan elkaar. Wat PHP doet is simpelweg een arbitraire waarde (0) nemen als een string niet castbaar is naar int. De situatie was imho niet anders geweest als ze bijv. 1337 als die arbitraire waarde hadden gekozen. Maar dan is iedereen het er ineens over eens dat het een complete absurditeit is.

Dat is ook niet inherent aan het feit dat het loose typed is, maar het speelt wel mee. Jij zou er voor kiezen om de vergelijking tot false te evalueren (valt zeker wat voor te zeggen), maar daarmee is het mijns inziens zeker niet fout een string die niet begint met cijfers naar 0 te "casten" (want echt casten is het niet, het is meer omzetten).

quote:

[...]
Waarom is '0' == 0 niet zinvol maar '1' == 1 wel?

Ik denk dat hij letterlijk de vergelijking "'0' = 0" bedoelt, welke inderdaad niet hardcoded in je script hoeft voor te komen. En dat gaat in feite op voor elke hardcoded vergelijking.

quote:

[...]

Zucht. Anders lees je mijn eerste reactie hierover nog eens door. De definitie staat mij idd niet aan. Wat ik me echter afvraag is hoe die definitie tot stand is gekomen. Omdat dat toevallig de bijwerking was van hoe de code is opgeschreven, of omdat ze er goed over hebben nagedacht? Gezien de overall design van PHP zet ik mijn geld in op dat eerste. En dat was nou juist de aanleiding van deze discussie.

Het is inderdaad goed mogelijk dat deze uitkomst het gevolg is van eerder gemaakte beslissingen. Maar dat neemt niet weg dat het niet mogelijk is dat het een bewuste beslissing is geweest om dit later niet af te vangen. Ook weet je simpelweg niet of het überhaupt op die manier tot stand is gekomen. Kun je wel over speculeren maar ik heb toch echt het idee dat dat niet de discussie is die we hier voeren.

quote:

[...]

Allereerst klopt je opmerking over "hogere programmeertalen" niet. PHP is gewoon 3GL, net als C++ en Java e.d. dat zijn. Maar even los daarvan, als wat jij zegt waar zou zijn, waarom wordt er dan zo weinig gebashed op andere talen die anders zijn? Zoals bijv. javascript?

Als je kijkt naar de strictere regels, naar de mensen die het gebruiken en de manieren waarop dan kun je m.i. PHP en C++, Java, etc. niet in hetzelfde rijtje zetten.

En alsof mensen zo gek zijn van javascript, wie heeft daar nou nog nooit een vreemd probleem mee gehad. De redenen die er zijn om het te gebruiken zijn over het algemeen noodzaak en gebrek aan alternatieven.

quote:

Natuurlijk zijn er veel napraters, maar dat neemt niet weg dat er weldegelijk wat te bashen valt met valide argumenten. Het feit dat dat populair zou zijn doet daar verder niets aan af. "Oh, shit, nu is het populair, nu kan het niet meer"

Ik ben net als jou van mening dat kritiek op bepaalde punten, mits ondersteund met goede argumenten, helemaal geen probleem is. Maar ik vind het vreemd hoe sommige mensen PHP direct afdoen om soms redelijk triviale punten. Vaak speelt gevoel daarin een grotere rol dan objectiviteit.

quote:

[...]

Niet dus, zie boven.

Wederom, het heeft er wel mee te maken want als PHP niet loose typed was dan zou het met de == operator gewoon naar false evalueren.

Instant update:

quote:

PHP is geen lagere GL dan een andere taal (waar jij op doelt); PHP is net zo 3GL als (bijv.) C#. If anything, dan is PHP zelfs een hogere GL

Slechte verwoording van mij, ik bedoel gewoon de strictere (en daarmee eigenlijk gewoon alle niet-loose typed) talen.

quote:

Patriot schreef op maandag 25 augustus 2008 @ 13:23:
Dat is ook niet inherent aan het feit dat het loose typed is, maar het speelt wel mee. Jij zou er voor kiezen om de vergelijking tot false te evalueren (valt zeker wat voor te zeggen), maar daarmee is het mijns inziens zeker niet fout een string die niet begint met cijfers naar 0 te "casten" (want echt casten is het niet, het is meer omzetten).

Euh ja, dat is wat casting betekent. De term casting komt uit de metaalbewerking - je giet een type als het ware in een andere vorm. Type conversion en typecasting zijn equivalent . Je zou het lexical casting kunnen noemen.

quote:

Het is inderdaad goed mogelijk dat deze uitkomst het gevolg is van eerder gemaakte beslissingen. Maar dat neemt niet weg dat het niet mogelijk is dat het een bewuste beslissing is geweest om dit later niet af te vangen. Ook weet je simpelweg niet of het überhaupt op die manier tot stand is gekomen. Kun je wel over speculeren maar ik heb toch echt het idee dat dat niet de discussie is die we hier voeren.

Inmiddels niet meer nee, maar dat krijg je als mensen selectief reageren . .oisyn in "[Alg] Slechtste programmeervoorbeelden d..." Overigens was de daadwerkelijke bugreport idd degene die Janoz daarna postte, en vergiste ik me dus in het specifieke voorbeeld. Het was verder niet mijn bedoeling om een discussie over == te ontketenen.

quote:

Wederom, het heeft er wel mee te maken want als PHP niet loose typed was dan zou het met de == operator gewoon naar false evalueren.

Dan heeft de big bang er ook mee te maken, want als die er niet was dan was PHP er ook niet geweest . Dat PHP besluit om true te returnen is geen direct gevolg van het feit dat het loose typed is - ze hadden immers ook kunnen besluiten om false te returnen. Dat ze die keuze niet meer konden maken als de situatie anders was geweest doet er in feite weinig toe.

Het ontbreken van type checking in PHP is ook geen "feature", maar is gewoon gedaan omdat het de implementatie makkelijker maakt(e). En dan zit je ineens al snel vast aan backward compatibility... Het wordt in ieder geval mooi vekocht onder de illusie dat het is om het programmeren makkelijker te maken en de learning curve lager

Ach, om het voor mij even af te ronden: Ik zal wel iets te fel reageren, maar ik vind het gewoon niet nodig om de hele taal af te schrijven omdat er bepaalde keuzes zijn gemaakt die wellicht niet optimaal waren. Van de twee voorbeelden die zijn genoemd is er ééntje mogelijk schadelijk, maar dat is eigenlijk alleen als een developer tegen de aanwijzingen van de documentatie in werkt.

EDIT: Niet om te zeggen dat iedereen die iets slechts heeft te zeggen over PHP de taal direct aan de kant zet hoor, is meer een rant in het algemeen dan tegen iemand die in deze discussie heeft gereageerd.

Patriot wijzigde dit bericht 25-08-2008 14:21 (21%)

quote:

Zoijar schreef op maandag 25 augustus 2008 @ 14:10:
Het ontbreken van type checking in PHP is ook geen "feature", maar is gewoon gedaan omdat het de implementatie makkelijker maakt(e). En dan zit je ineens al snel vast aan backward compatibility... Het wordt in ieder geval mooi vekocht onder de illusie dat het is om het programmeren makkelijker te maken en de learning curve lager

?? het lijkt mij zelf toch makkelijker als je van te voren al precies weet wat voor type iets is en er dan mee te rekenen dan met loose types te werken en converteer algoritmes te moeten werken en types proberen te herkennen on the fly.

Voorbeeld:
code:

int i = 10;
string s = "10";
if(s.CompareTo(i.toString()) == 0)
{
//doe iets
}

Lijkt me een veel makkelijker te programmeren programmeer taal dan.
code:

if(10 == "10")
{
//doe iets.
}

Immers moet bij optie 2 de compiler gokken wat voor types hij mee te maken heeft (10 kan een long, double, int of byte zijn) en moet dus proberen 10 te converteren nav een vrij uitgebreide parse tree en dan daar de equals methode (wat == eigenlijk doet) van vinden die een string als input kan gebruiken. Tough job dan maak ik liever een compiler die gewoon weet, dit is een integer en die roept die methode aan.

Dus makkelijker te implementeren wil ik het absoluut niet noemen.

(Verder ben ik trouwens een 'tegenstander' van php voor alles behalve sommige web applicaties en vind ik persoonlijk dat ze ook voor webapps terein verliezen aan bijvoorbeeld .Net, een nette taal als C# kunnen gebruiken in websites is toch veel netter dan php nu is imho.