De toekomst van PHP-development*

[Verwijderd]

Meer dan 2 maanden geleden was de eerste RC uit van PHP 5.1
Die werd vermeld op php.net met als optimistisch commentaar dat er over enkele weken een release zou volgen.
Maar die kwam niet. En inmiddels is zelfs de aankondiging van RC1 verdwenen van php.net????

Watskeburt? Gaat het niet goed met de ontwikkeling van PHP?

Ik zat juist zo te wachten op de vernieuwingen, de nieuwe libpcre enz..

Weet iemand hier de 8rgronden van?

[Peter]

Verwijderd schreef op zaterdag 12 november 2005 @ 13:18:
Meer dan 2 maanden geleden was de eerste RC uit van PHP 5.1
Die werd vermeld op php.net met als optimistisch commentaar dat er over enkele weken een release zou volgen.
Maar die kwam niet. En inmiddels is zelfs de aankondiging van RC1 verdwenen van php.net????

Watskeburt? Gaat het niet goed met de ontwikkeling van PHP?

Ik zat juist zo te wachten op de vernieuwingen, de nieuwe libpcre enz..

Weet iemand hier de 8rgronden van?

De PHP crew is weer redelijk opgedeeld vermoed ik, gezien de eerste dev releases van PHP6 ook beginnen te verschijnen. Misschien kan je iets terugvinden in de php.internals mailing lists (google).

[elevator]

Ik geloof dat er sowieso besloten was om RC's niet meer op de PHP.net index page te zetten.

De RC's staan wel hier: http://downloads.php.net/ilia/ en dan kan je zien dat ze op RC4 zitten

[twiekert]

Wel een beetje jammer dat RC1 ergens in augustus uitkwam met als positief puntje dat ze binnen "enkele weken" een officiele release wilden doen. Vervolgens laten ze 2 maanden helemaal niks van zich horen, verwijderen op dat punt het RC1 nieuwsbericht van de frontpage, en nu weer een maand later, nog steeds niks

Ergens op google in wat mailinglists had ik terug gevonden dat PHP 5.1 gereleased zou worden "no later than november 10th". Beetje jammer dat voor zo'n mooie release er gewoon niet duidelijk gecommuniceerd kan worden waarom het zoveel langer duurt en nu weer dat de target release date niet gehaald kan worden.

Het is natuurlijk dan wel opensource software/php license maar met zo'n veel gebruikte web-programmeertaal als php met een mega community heb je toch ook wel een verantwoordelijkheid naar je gebruikers toe..

/edit
hier staat wat meer info over de php 5.1 release candidates:
http://ilia.ws/archives/88-PHP-5.1.0RC4-is-out!.html

[ Voor 14% gewijzigd door twiekert op 12-11-2005 13:44 ]

[Verwijderd]

"PHP: Because 1000000 newbies can't be wrong."

Modbreak:

Ah. En ga je dat nu in elk topic vertellen waar PHP in de titel staat? Nee? Mooi.

[ Voor 57% gewijzigd door NMe op 12-11-2005 14:44 ]

[NMe]

Hmm, hier kan verder niet veel discussie meer uitkomen ben ik bang. De downloads zijn gevonden, de redenen waarom ze niet meer op de main page staan zijn ook verteld.

Ik wil dit topic wel open laten, op voorwaarde dat er gediscussiëerd gaat worden over de nieuwe features, maar als het over die verdwenen downloads blijft gaan, dan is dit geen topic meer waard hier in P&W.

[CyBeR]

Overigens was PHP5.1RC1 nogal crash-prone bij mij.

[GX]

CyBeR schreef op zaterdag 12 november 2005 @ 14:48:
Overigens was PHP5.1RC1 nogal crash-prone bij mij.

Ik heb er tot nu toe nog geen problemen mee gehad; het draait vrij soepeltjes zelfs . Ik moet echter nog wel veel van de nieuwe functies uberhaupt uitproberen.

[mr_star]

Heeft er al iemand gespeeld met de database layer (pdo)? Ik heb tot nu toe altijd gewerkt met een eigen database abstraction layer, maar ik vraag mij af welke indruk jullie al hebben van pdo. Het valt mij trouwens op dat ik nergens iets tegenkom mbt cachen van query resultaten. Ik veronderstel dus dat dit (nog?) niet ondersteund wordt.

Ze zijn in mijn ogen al goed op weg om van het hobby imago af te komen, maar aan de PR zouden ze toch nog meer aandacht mogen besteden.

[bartvb]

En van een aantal mensen in het internals team wordt je ook niet blij. 'screw backwards compatibility', bweeh.

Een van de problemen met 5.1 was dat ze ineens iets mbt references hadden veranderd waardoor HEEL veel bestaande code ineens niet meer werkte. Een (voor de gemiddelde PHP programmeur) volstrekt onlogische wijziging om een probleem op te lossen in de engine zelf. Niet slim. Ik heb het toen een tijdje gevolgd (omdat er echt heel veel ineens niet meer draaide) maar ging daarna op vakantie. Daarna niet meer gekeken. Van wat ik wel meegekregen heb werd ik iig niet blij, gelukkig zijn er nog wel een aantal mensen in het internals team die het wel snappen (Andi b.v.) maar een fan van b.v. Derick ben ik niet

Tijdens het maken van RC1 en RC2 is er ook flink wat discussie ontstaan over dit soort problemen en men is toen tot de conclusie gekomen dat er eens goed nagedacht moet worden over de manier waarop releases worden uitgebracht. Er is toen ook het plan opgevat om iets op te zetten met een aantal grote opensource projecten maar daar heb ik verder weinig meer van gehoord.

PDO? Tja, is leuk, soort van iig, maar een jaar of 6 te laat. Is alleen te gebruiken op de aller, aller, aller nieuwste PHP versies, gaat (iig voor mij) nog een flinke tijd duren voor ik daar wat mee kan. Verder heeft het niet echt toegevoegde waarde boven 95% van de bestaande DBALs (die wel overal op draaien).

[Skaah]

bartvb schreef op zaterdag 12 november 2005 @ 16:01:PDO? Tja, is leuk, soort van iig, maar een jaar of 6 te laat. Is alleen te gebruiken op de aller, aller, aller nieuwste PHP versies, gaat (iig voor mij) nog een flinke tijd duren voor ik daar wat mee kan. Verder heeft het niet echt toegevoegde waarde boven 95% van de bestaande DBALs (die wel overal op draaien).

Waarom is er eigenlijk gekozen voor een eigen DBAL? Is er iets mis met PEAR_DB? DIt lijkt me een veel gebruikte, prima DBAL.

[twiekert]

De belangrijkste features van php 5.1 zijn voor mij:

- PDO (standaard meegeleverd met 5.1 release)
- SPL (implementatie interfaces van veelgebruikte design patterns (iterator, observer etc)
- type hinting voor classes en arrays

Ik ga met deze nieuwe features de komende 6 maanden goed aan de slag voor een nieuw project

Waarom is er eigenlijk gekozen voor een eigen DBAL? Is er iets mis met PEAR_DB? DIt lijkt me een veel gebruikte, prima DBAL.

Een eigen database access layer implementeren en standaard meeleveren met de PHP distributie wordt veel sneller geaccepteerd dan dan dat er iets via PEAR geinstalleerd moet worden.

mr_star schreef op zaterdag 12 november 2005 @ 15:50:
Heeft er al iemand gespeeld met de database layer (pdo)? Ik heb tot nu toe altijd gewerkt met een eigen database abstraction layer, maar ik vraag mij af welke indruk jullie al hebben van pdo. Het valt mij trouwens op dat ik nergens iets tegenkom mbt cachen van query resultaten. Ik veronderstel dus dat dit (nog?) niet ondersteund wordt.

Ze zijn in mijn ogen al goed op weg om van het hobby imago af te komen, maar aan de PR zouden ze toch nog meer aandacht mogen besteden.

De vraag is natuurlijk, waar moeten die resultaten gecached worden? PHP is niet persistent: bestand geparsed? Data weg . Resultaten van queries cachen binnen een pagina zal alleen nut hebben als je die gegevens meer dan 1x nodig hebt.

Veel gebruikte gegevens uit een database die bijna nooit wijzigen kan je natuurlijk wel cachen in een SESSION (per user) of een memcache addon voor php (globaal).
MySQL daarentegen heeft al een SQL result cache geimplementeerd vanaf 4.0, dus dan heb je ook al heel weinig overhead.

[ Voor 46% gewijzigd door twiekert op 12-11-2005 17:21 ]

[GX]

En interne code is altijd nog sneller dan een library (PEAR_DB) welk ook nog geinterpreteerd moet worden. Stap vooruit dus.

Wat betreft backwards comptability? Jammer dan. Als PHP op die manier naar een "echte" taal kan groeien en dingen gaat ondersteunen zoals het hoort kan ik er alleen maar blij mee zijn.

[ Voor 67% gewijzigd door GX op 12-11-2005 17:51 . Reden: nietszeggende quote weg ]

[Wim-Bart]

Ik zit eigenlijk meer te wachten op fixed types. Dus dat je niet met settype aan de gang hoeft, want settype is eigenlijk een wazig gedoe.

PHP:

$iTemp = 10;
settype($iTemp,'integer');
$iTemp = $iTemp.'Hallo';
echo $iTemp;

Ik zou liever dit hebben:

PHP:

declare $iType as integer; // of define of var of typedef of whatever

$iTemp = 10;
$iTemp = $iTemp."Hallo";          // <- genereerd een error!
echo $iTemp;

[NMe]

Reken er maar niet op dat fixed types ooit mainstream zullen worden voor PHP. Weak typing is juist de grootste reden waarom die taal zo immens populair is en in principe iedere n00b ermee aan de gang kan. Misschien dat er in de toekomst een optie komt waarmee je strong typing aan kan zetten, maar ik gok dat niet veel hosts die optie standaard aan gaan zetten omdat dan waarschijnlijk letterlijk geen van de huidige scripts nog zal werken. Mooie manier om klanten te verliezen.

Overigens zou ik zelf natuurlijk wel strong typing willen zien in PHP, het is gewoon dat ik het uit realistisch oogpunt niet zo snel zie gebeuren.

[Dennis]

twiekert schreef op zaterdag 12 november 2005 @ 17:12:
De belangrijkste features van php 5.1 zijn voor mij:
- type hinting voor classes en arrays

Voor classes zit iig ook al in php 5.0.

[Dennis]

-NMe- schreef op zaterdag 12 november 2005 @ 18:34:
Reken er maar niet op dat fixed types ooit mainstream zullen worden voor PHP. Weak typing is juist de grootste reden waarom die taal zo immens populair is en in principe iedere n00b ermee aan de gang kan. Misschien dat er in de toekomst een optie komt waarmee je strong typing aan kan zetten, maar ik gok dat niet veel hosts die optie standaard aan gaan zetten omdat dan waarschijnlijk letterlijk geen van de huidige scripts nog zal werken. Mooie manier om klanten te verliezen.

Overigens zou ik zelf natuurlijk wel strong typing willen zien in PHP, het is gewoon dat ik het uit realistisch oogpunt niet zo snel zie gebeuren.

Ik zou niet weten waarom het niet gewoon beide zou kunnen blijven bestaan. Als je een variabele declareert voor een bepaald type is het dat type, en anders is het gewoon 'weak'. Lijkt mij dat dat niet moeilijk realiseerbaar is.

[NMe]

Dennis schreef op zaterdag 12 november 2005 @ 18:35:
Voor classes zit iig ook al in php 5.0.

Maar het wordt niet afgedwongen, en je komt er dus makkelijk omheen. Sowieso slaat het nergens op dat je wel type hinting van je eigen classes kan toepassen, maar je kan niet hinten naar een basistype als integer of double. Ik vind het maar een halfzachte implementatie eerlijk gezegd, ook als in 5.1 dan eindelijk type hinting van arrays wordt ondersteund.

Dennis schreef op zaterdag 12 november 2005 @ 18:37:
Ik zou niet weten waarom het niet gewoon beide zou kunnen blijven bestaan. Als je een variabele declareert voor een bepaald type is het dat type, en anders is het gewoon 'weak'. Lijkt mij dat dat niet moeilijk realiseerbaar is.

In dat geval krijg je VB taferelen: maak je een tikfout in je variabelenaam, dan kun je ineens alles doen. Dan moet er dus ook zoiets komen als "Option Explicit" in VB.

Verder: als je mensen de keus laat tussen strong typed en weak typed, dan zal in verhouding maar een klein groepje mensen strong typed variabelen gaan gebruiken. Dankzij die relatief kleine doelgroep zal strong typing niet echt hoog op de prioriteitenlijst staan van de developers, al zou hun taal een stuk professioneler overkomen als ze het eindelijk eens invoeren.

[Dennis]

-NMe- schreef op zaterdag 12 november 2005 @ 18:46:
Maar het wordt niet afgedwongen, en je komt er dus makkelijk omheen. Sowieso slaat het nergens op dat je wel type hinting van je eigen classes kan toepassen, maar je kan niet hinten naar een basistype als integer of double. Ik vind het maar een halfzachte implementatie eerlijk gezegd, ook als in 5.1 dan eindelijk type hinting van arrays wordt ondersteund.

Ja inderdaad, die type hinting voor arrays zet ook niet echt zoden aan de dijk. Php kan echt op een stuk meer steun van mijn kant (en vast ook anderen) rekenen als er volledige type hinting support in zit. Of dat nou verplicht of optioneel is maakt mij niet zoveel uit.

In dat geval krijg je VB taferelen: maak je een tikfout in je variabelenaam, dan kun je ineens alles doen. Dan moet er dus ook zoiets komen als "Option Explicit" in VB.

Uiteraard.

Verder: als je mensen de keus laat tussen strong typed en weak typed, dan zal in verhouding maar een klein groepje mensen strong typed variabelen gaan gebruiken. Dankzij die relatief kleine doelgroep zal strong typing niet echt hoog op de prioriteitenlijst staan van de developers, al zou hun taal een stuk professioneler overkomen als ze het eindelijk eens invoeren.

Dat een hoop mensen die php gebruiken geen type hinting zullen gebruiken ben ik met je eens, maar dat maakt niet zoveel uit. Als type hinting er éénmaal in zit hoeft er verder niet veel meer aan te gebeuren lijkt mij, door het php ontwikkelteam.

Verder vind ik trouwens namespaces (ook in php 5.1) een goed pluspunt. Ik heb de specificaties nog niet bekeken maar ik begreep wel dat de php implementatie helaas niet zo geweldig is. Nu nog de Zend engine een stuk wijder verspreiden en er is alweer een heleboel vooruitgang geboekt.

[NMe]

Gaat PHP 5.1 namespaces ondersteunen? Het laatste dat ik over namespaces las was dat het in PHP5 zou komen, maar uiteindelijk toch niet erin is gezet. Ik heb me niet echt verdiept in de specificaties, dus ik weet maar een paar dingen, maar als er inderdaad namespaces in PHP 5.1 komen, dan is dat al een mooie stap in de goede richting.

[Genoil]

-NMe- schreef op zaterdag 12 november 2005 @ 19:41:
Gaat PHP 5.1 namespaces ondersteunen? Het laatste dat ik over namespaces las was dat het in PHP5 zou komen, maar uiteindelijk toch niet erin is gezet. Ik heb me niet echt verdiept in de specificaties, dus ik weet maar een paar dingen, maar als er inderdaad namespaces in PHP 5.1 komen, dan is dat al een mooie stap in de goede richting.

Nee, die komen er helaas niet in. Een of andere Jesse schijnt een patch te hebben ontwikkeld waarmee je het aan kunt zetten, maar zijn werk en die patch wordt vooralsnog genegeerd door het dev team. Na een discussie hier over op de Propel mailinglist is er besloten contact te zoeken met andere grote PHP5 projecten die nut zouden hebben van namespaces met als doel een front te vormen tegenover het dev team om namespaces support alsnog te integreren in een toekomstige release. Ik denk zelf dat dit niet 5.1 zal zijn...

[NMe]

Hmm, ik kon er zelf inderdaad ook al niets meer over vinden. Je gaat je toch afvragen wat een developersteam zulke keuzes laat maken. Namespaces, fatsoenlijk OO en strong typing zouden het n00b-karakter van de taal eindelijk eens uit de weg kunnen ruimen, maar het dev-team lijkt als een bezetene vast te houden aan oude "ontwerpfouten". "Ontwerpfouten" is natuurlijk een groot woord, zeker aangezien ze waarschijnlijk voortgekomen zijn uit bewuste keuzes, maar ik kan de taal steeds minder serieus nemen op deze manier.

[Genoil]

phpnamespaces heet dat verzetsgroepje dus. Is momenteel weinig meer dan geregistreerd domein met een disfunctionele Wiki, maar daar zou binnenkort wel iets moeten gebeuren.

[.oisyn]

bartvb schreef op zaterdag 12 november 2005 @ 16:01:
En van een aantal mensen in het internals team wordt je ook niet blij. 'screw backwards compatibility', bweeh.

Kom op, daarmee kunnen ze PHP eindelijk volwassen maken. Hun huidige design suckt aan alle kanten, PHP5 was een imho mislukte poging om dat te verhelpen. De enige manier om daar vanaf te komen is dmv breaking changes. Natuurlijk, het is even doorbijten, maar het wordt er wel beter van. Ze zouden evt. een transitieperiode in kunnen voeren waar beide system in de interpreter ingebouwd zitten. Of een tool die oude code convert naar nieuwe.

.edit: wat is eigenlijk ooit de reden geweest om namespaces toch maar niet te implementeren?

[ Voor 7% gewijzigd door .oisyn op 12-11-2005 23:01 ]

[pierre-oord]

-NMe- schreef op zaterdag 12 november 2005 @ 18:34:
Reken er maar niet op dat fixed types ooit mainstream zullen worden voor PHP. Weak typing is juist de grootste reden waarom die taal zo immens populair is en in principe iedere n00b ermee aan de gang kan. Misschien dat er in de toekomst een optie komt waarmee je strong typing aan kan zetten, maar ik gok dat niet veel hosts die optie standaard aan gaan zetten omdat dan waarschijnlijk letterlijk geen van de huidige scripts nog zal werken. Mooie manier om klanten te verliezen.

Overigens zou ik zelf natuurlijk wel strong typing willen zien in PHP, het is gewoon dat ik het uit realistisch oogpunt niet zo snel zie gebeuren.

Kan iemand mij uitleggen wat je er vrolijk van wordt bij een verschil tussen integer en string ofzo?

Ik declare overigens helemaal niets. Scheelt code is simpel. PHP is juist zo fijn op deze manier, als ik mensen in C iets zie programmeren wordt ik gek, die zijn gewoon tig regels kwijt voor een paar simpele dingen.

Is het sneller ofzo als je iets als integer van begin af aan al vastzet ofzo? Of is het iets in jullie hoofd dat graag een link wil leggen naar een andere programmeertaal ofzo en wil aantonen dat je toch wel heel wat 1337-er bent omdat je alles netjes doet zoals het ook in een "echte" programmeer taal is? (nofi )

edit:
O ja, ik vind het prima als ze nieuwe dingen willen maken en oude dingen niet meer willen ondersteunen. Maar laten ze er dan toch astjeblieft een optie in maken die je aan en uit kan zetten met INI_SET of in een virtual host, zodat oude apps niet breken. Ik vond het nu al een ramp te upgraden naar PHP5, veel problemen bij mensen, heb overal kleine dingen moeten bijscripten/weghalen/verbeteren om oudere forums etc nog te laten werken.

[ Voor 15% gewijzigd door pierre-oord op 12-11-2005 23:09 ]

[ACM]

pierre-oord schreef op zaterdag 12 november 2005 @ 23:07:
Is het sneller ofzo als je iets als integer van begin af aan al vastzet ofzo?

Als er geen conversies bij operaties nodig én mogelijk zijn dan kan de hele afhandeling van variabelen in principe wat eenvoudiger gedaan worden en dus is het inderdaad sneller. Er hoeft dan bijvoorbeeld bij een vermenigvuldiging niet eerst gekeken te worden of de operands wel getallen zijn. Doordat de code door de compiler kwam weet je al dat dat het geval is.
Normaliter wordt php niet gebruikt voor applicaties waar dat soort micro-optimalisaties erg veel uitmaken, dus is dat maar een klein voordeel voor het gros van de applicaties.

Een ander voordeel is dat je veel beter weet wat iets is en dat levert zelfs wat extra veiligheid op. SQL-injectie wordt bijvoorbeeld een stuk lastiger als je een integer gebruikt ipv een variabele die "een integer voorstelt" (en omdat ie uit GET/POST komt dus per definitie string is).

Nadelen zijn er natuurlijk ook. Je moet tenslotte variabelen converteren van het ene naar het andere type als je er bepaalde operaties op wilt doen. Een getal pretty-printen door hem char-wise af te lopen en na elke 3 cijfers een punt te concattenaten gaat je niet lukken in een strong-typed taal zonder eerst het getal naar string te converteren. In php en andere weak-typed talen wordt dat uiteraard automatisch gedaan.
Je hoeft dus gewoon veel minder op te letten wat iets is en daardoor kan het dev-proces vaak wat sneller doorlopen worden. Vaak maakt het in webapps helemaal niet zoveel uit wat iets nou precies is. Als je een getal alleen maar tussen de html wil printen zonder verdere operaties erop, moet het uiteindelijk toch een string zijn en kan het je echt niet schelen of het nou een int, double, float of string was.

Of is het iets in jullie hoofd dat graag een link wil leggen naar een andere programmeertaal ofzo en wil aantonen dat je toch wel heel wat 1337-er bent omdat je alles netjes doet zoals het ook in een "echte" programmeer taal is? (nofi )

Dat zal zeker meespelen, het psychologische aspect.

[.oisyn]

pierre-oord schreef op zaterdag 12 november 2005 @ 23:07:

Kan iemand mij uitleggen wat je er vrolijk van wordt bij een verschil tussen integer en string ofzo?

Het geeft cleanere code. Als een functie een int verwacht, dan mag je 'm geen string geven. En dus wil je dat je een waarschuwing krijgt als je per ongeluk wel een string geeft. Bij objecten is dit een nog veel belangrijkere eigenschap, je wilt namelijk weten wat het is waar je mee werkt. Daarnaast heeft OO weinig nut als je geen strictere typechecking hebt; wat is het nut van een interface definitie als je ook een compleet ander object kan gebruiken dat toevalligerwijs een aantal functies met dezelfde naam implementeert?

Als je nette php code wil schrijven dan zul je hier zelf op moeten checken. Je bent dus helemaal niet sneller klaar, dat geldt alleen als je ranzige code schrijft en nergens op controleert.

Ik declare overigens helemaal niets. Scheelt code is simpel. PHP is juist zo fijn op deze manier, als ik mensen in C iets zie programmeren wordt ik gek, die zijn gewoon tig regels kwijt voor een paar simpele dingen.

C is ook kut, maar in C++, C# of Java bijvoorbeeld ben je echt niet meer regels kwijt hoor.

Is het sneller ofzo als je iets als integer van begin af aan al vastzet ofzo? Of is het iets in jullie hoofd dat graag een link wil leggen naar een andere programmeertaal ofzo en wil aantonen dat je toch wel heel wat 1337-er bent omdat je alles netjes doet zoals het ook in een "echte" programmeer taal is? (nofi )

"nofi", maar als je al niet eens snapt waar strict typing handig voor is ben je imho ook nog niet echt zo'n ervaren programmeur, zeker als je ook nog eens gaat zeggen dat een reden om het te gebruiken is dat je je dan 1337 zou voelen. Dat is iets voor pubers.

[NMe]

.oisyn schreef op zaterdag 12 november 2005 @ 23:38:
Het geeft cleanere code. Als een functie een int verwacht, dan mag je 'm geen string geven. En dus wil je dat je een waarschuwing krijgt als je per ongeluk wel een string geeft. Bij objecten is dit een nog veel belangrijkere eigenschap, je wilt namelijk weten wat het is waar je mee werkt. Daarnaast heeft OO weinig nut als je geen strictere typechecking hebt; wat is het nut van een interface definitie als je ook een compleet ander object kan gebruiken dat toevalligerwijs een aantal functies met dezelfde naam implementeert?

Als je nette php code wil schrijven dan zul je hier zelf op moeten checken. Je bent dus helemaal niet sneller klaar, dat geldt alleen als je ranzige code schrijft en nergens op controleert.

Daarbij komt nog dat als je met code van anderen werkt, je niet direct weet hoe alles in elkaar steekt. Je gaat een functie dingen voeren, maar misschien doe je het wel fout. Ik krijg in zo'n geval liever een dikke error van de parser omdat ik er een string in stop waar ie een integer verwacht, dan dat ik 3 dagen loop te debuggen op een stomme fout.

[prototype]

Het grootste puntje van kritiek dat ik heb bij weaktypen is dat ik, indien ik veiligheid wil handhaven, ontiegelijk veel defensief aan het coden ben. Dit maakt de code groot en op den duur minder onderhoudbaar. Opzich heeft weaktypen wel voordelen, maar ik zie niet waarom dat niet kan icm strongtype. Zo meende ik hier onlangs een topic gelezen te hebben die uitwijdde over 'var', die in .net 2 talen zou komen verschijnen.

[.oisyn]

-NMe- schreef op zaterdag 12 november 2005 @ 23:47:
[...]

Daarbij komt nog dat als je met code van anderen werkt, je niet direct weet hoe alles in elkaar steekt. Je gaat een functie dingen voeren, maar misschien doe je het wel fout. Ik krijg in zo'n geval liever een dikke error van de parser omdat ik er een string in stop waar ie een integer verwacht, dan dat ik 3 dagen loop te debuggen op een stomme fout.

Idd, en als documentatie op zichzelf is het natuurlijk ook enorm handig.

[ACM]

.oisyn schreef op zaterdag 12 november 2005 @ 23:38:
Het geeft cleanere code.

Dat is maar een kwestie van wat je cleaner vindt Aangezien je juist meer aandacht moet besteden aan wat voor type iets is, komt er ook per definitie meer code in je applicatie te staan.

Als een functie een int verwacht, dan mag je 'm geen string geven. En dus wil je dat je een waarschuwing krijgt als je per ongeluk wel een string geeft.

Klopt, maar moet die waarschuwing per se bij het compileren komen? (Let er op dat de meeste weak-typed talen veel korter compileren) Of mag het ook bij het unit-testen opduiken? Want ook als het niet uitmaakt of het een int of string was krijg je in strong-typed omgevingen een waarschuwing.
Sterker nog, als je een functie overload voor ints en strings en je hebt dus syntactisch correcte code, hoeft dat nog niet te betekenen dat je ook semantisch goede code geschreven hebt. Daar kom je ook alleen maar met (unit-)testing achter.

Bij objecten is dit een nog veel belangrijkere eigenschap, je wilt namelijk weten wat het is waar je mee werkt.

Dat hangt er van af. De standaard containers in java konden tot de introductie van generics al niet gebruikt worden met type-informatie, het enige wat je wist was dat het een object was.
En class-casting kan ook fout gaan, je zou dat zelfs een vorm van weak-typing kunnen noemen.

Daarnaast heeft OO weinig nut als je geen strictere typechecking hebt; wat is het nut van een interface definitie als je ook een compleet ander object kan gebruiken dat toevalligerwijs een aantal functies met dezelfde naam implementeert?

Dat is denk ik in veel gevallen helemaal niet zo relevant. Bovendien kan je er wel degelijk achter komen en heb je de vrijheid niet de boel expliciet te checken waar het niet nodig is.

Als je nette php code wil schrijven dan zul je hier zelf op moeten checken. Je bent dus helemaal niet sneller klaar, dat geldt alleen als je ranzige code schrijft en nergens op controleert.

Je bent wel degelijk sneller klaar als het in de meeste gevallen niet uitmaakt. Voor de aanroep van een toString-methode hoef je niet te weten of iets een Object, een String of whatever is in Java. Het heeft toch wel een toString.

C is ook kut, maar in C++, C# of Java bijvoorbeeld ben je echt niet meer regels kwijt hoor.

Als je inderdaad van elke variabele zeker wilt weten wat het is, dan ben je niet meer code kwijt. De meeste winst in code komt sowieso niet door puur het overboord gooien van type-specificaties, maar meer vanwege allerlei andere shortcuts in de taal.

"nofi", maar als je al niet eens snapt waar strict typing handig voor is ben je imho ook nog niet echt zo'n ervaren programmeur, zeker als je ook nog eens gaat zeggen dat een reden om het te gebruiken is dat je je dan 1337 zou voelen. Dat is iets voor pubers.

Niettemin is het wel degelijk deels psychologisch. En ik ben niet de enige die dat vindt, bekende mensen als Bruce Eckel en (volgens hem) Martin Fowler zeggen hetzelfde.
Je moet tenslotte toch wel testen, want weten dat iets compileert zegt je bij complexe applicaties vooral dat je geen syntactische fouten hebt gemaakt (ik wilde "typefouten" zeggen, maar dat woord is wat dubbelzinnig ), maar het zegt maar heel beperkt wat over de kwaliteit van je code.
Het voordeel dat PHP, Python, Perl etc hebben is dat je niet tientallen seconden op de compilatie moet wachten en dat je dus sneller aan het testen kan gaan.

Overigens zie ik in beide systemen voordelen en heb ik geen met geen van beide moeite ze te gebruiken. Hier zijn trouwens nog wat meer online discussies.

.oisyn schreef op zondag 13 november 2005 @ 00:23:
Idd, en als documentatie op zichzelf is het natuurlijk ook enorm handig.

Als je aan de hand van de type-informatie moet achterhalen wat voor type een object is, moet je wellicht ook wat aan je naamgeving doen, hoewel ik het wel met je eens ben dat het er wel nog duidelijker van kan worden.

[ Voor 8% gewijzigd door ACM op 13-11-2005 10:43 ]

[PrisonerOfPain]

.oisyn schreef op zaterdag 12 november 2005 @ 22:59:
.edit: wat is eigenlijk ooit de reden geweest om namespaces toch maar niet te implementeren?

Ik denk veel van dit soort issues, alleen zien de problemen er niet 'onoplosbaar' uit op de een of andere manier. Terwijl dit wel door Zeev aangehaald word als een van de 'conceptuele' redenen om het niet te implementeren.

[Verwijderd]

ACM schreef op zondag 13 november 2005 @ 10:41:Je bent wel degelijk sneller klaar als het in de meeste gevallen niet uitmaakt. Voor de aanroep van een toString-methode hoef je niet te weten of iets een Object, een String of whatever is in Java. Het heeft toch wel een toString.

Wat een hoop bullshit bij elkaar, waarvan dit toch wel de grootste. Om toString aan te kunnen roepen moet je JUIST weten dat het een Object is. Een primitief type heeft echt geen toString methode.

[aex351]

php conventeert in de inhoud van een string toch naar de juiste type, deze check word zowiezo iedere keer uit gevoerd dus ik denk niet dat het sneller is als je alles gaat casten of wat dan ook.

[NMe]

aex351 schreef op zondag 13 november 2005 @ 13:41:
php conventeert in de inhoud van een string toch naar de juiste type, deze check word zowiezo iedere keer uit gevoerd dus ik denk niet dat het sneller is als je alles gaat casten of wat dan ook.

Het zal even snel zijn; PHP moet zelf immers ook intern gaan casten. Ook in PHP zal bijvoorbeeld een string intern gewoon een array van chars zijn, afgesloten met een \0.

Het snelheidsargument voor fixed typed variabelen is denk ik wat zwak, maar het argument dat je duidelijkere code krijgt, waar iemand anders (en jijzelf ook) sneller mee aan de slag kan is wel degelijk geldig.

[PrisonerOfPain]

aex351 schreef op zondag 13 november 2005 @ 13:41:
php conventeert in de inhoud van een string toch naar de juiste type, deze check word zowiezo iedere keer uit gevoerd dus ik denk niet dat het sneller is als je alles gaat casten of wat dan ook.

Nu word er ook al vanalles gecast, maar doe je het niet zelf (expliciet) maar doet de interpreter het voor je (impliciet) kans is groot dat de interpreter vaker waarden cast als waneer je het zelf zou doen. Als de interpreter het niet voor jou hoeft te doen heb je er meer controle over en weet je precies wanneer het gebeurt.

[ACM]

Verwijderd schreef op zondag 13 november 2005 @ 13:27:
Wat een hoop bullshit bij elkaar

Ach, is het werkelijk zo erg?

Dan vraag ik me toch af wat JavaScript, Python, Smalltalk en anderen (die dus dynamic typing hebben) toch redelijk succesvol maakt.

waarvan dit toch wel de grootste. Om toString aan te kunnen roepen moet je JUIST weten dat het een Object is. Een primitief type heeft echt geen toString methode.

Achja, probeer een voorbeeld onderuit te trappen door het superstrikt te intepreteren. Je moet inderdaad weten dat het een object is, maar in principe mag je daar in veel code wel gewoon van uit gaan dat je een object meekreeg. Maar het soort object is niet relevant.
Waarom strikt checken terwijl je toch in 99% van de gevallen ook daadwerkelijk een object krijgt. Was het geen object, dan krijg je wel een runtime-like exception en dat vang je met de unit-testing wel af in je applicatie.

[ Voor 3% gewijzigd door ACM op 13-11-2005 14:55 ]

[Dutchmega]

Het schijnt dat ze ook al bezig zijn met het brainstormen voor PHP6. Ze willen al wat meer drastistische wijzingen doorvoeren (magic_quotes_* en register_globals verwijderen, bron). Van mij mogen ze het gerust een wat meer volwassen taal van maken. Ze zijn toch al goed in het bijhouden van meerdere versies.

[ Voor 9% gewijzigd door Dutchmega op 13-11-2005 15:33 ]

[NMe]

Die aanpassingen die daar gesuggereerd worden voor PHP6 zouden wat mij betreft meteen ingevoerd mogen worden. Maar ik zie het somber in: het is een voorstel, en geen plan.

[Verwijderd]

Ik vraag me af wanneer de grote control panels een update naar php5 gaan overwegen!! Laat staan php6, ik denk dat dat niks gaan worden met te veel breaks.

Waarom is het geen optie om een global te setten welke php versie parser het moet afhandelen?

PHP_TYPE = 4/5/6;

[Confusion]

ACM schreef op zondag 13 november 2005 @ 10:41:
Het voordeel dat PHP, Python, Perl etc hebben is dat je niet tientallen seconden op de compilatie moet wachten en dat je dus sneller aan het testen kan gaan.

Wat uitnodigt om elke 2 regels weer eens te compilen om te zien of het zaakje wel compileert, in plaats van goed na te denken over de code en na 20 regels tot je genoegen te merken dat er geen fouten in zitten. Dan duurt het compileren misschien langer, maar uiteindelijk is het toch sneller en heb je beter nagedacht en dus betere code geproduceerd. Werkende code is nog geen goede code.

[Verwijderd]

mhh, heeft men echt zoveel last van compilatie problemen? meestal zit er een of 2 fouten per 100 regels bij mij (java). Het compileren is dat echt niet het bottleneck...

[ACM]

Confusion schreef op zondag 13 november 2005 @ 16:51:
Wat uitnodigt om elke 2 regels weer eens te compilen om te zien of het zaakje wel compileert, in plaats van goed na te denken over de code en na 20 regels tot je genoegen te merken dat er geen fouten in zitten. Dan duurt het compileren misschien langer, maar uiteindelijk is het toch sneller en heb je beter nagedacht en dus betere code geproduceerd. Werkende code is nog geen goede code.

Een goede editor parsed natuurlijk je file on-the-fly zodat de meeste compilatiefouten er toch wel uitgehaald worden, zodat die hele compilatiestap steeds minder nodig is.

[Confusion]

ACM schreef op zondag 13 november 2005 @ 17:19:
Een goede editor parsed natuurlijk je file on-the-fly zodat de meeste compilatiefouten er toch wel uitgehaald worden, zodat die hele compilatiestap steeds minder nodig is.

Ik vind dat on-the-fly compilen net zo irritant als automatische spellingscorrectie in Word. Belangrijker is de overweging dat als ik het niet goed kan schrijven zonder die hints, dat ik het dan gewoon uberhaupt niet kan. Als doorgewinterde programmeur kan je het rustig aanzetten, maar beginners zouden het zonder moeten doen.

[bartvb]

.oisyn schreef op zaterdag 12 november 2005 @ 22:59:
[...]De enige manier om daar vanaf te komen is dmv breaking changes. Natuurlijk, het is even doorbijten, maar het wordt er wel beter van.[...]

Dat is leuk en aardig maar daar maak je geen vrienden mee. Ik durf er redelijk wat om te verwedden dat minder dan 10% van de hosters over is op PHP5 en 5 is toch al een flinke tijd uit. Waarom gaan die hosters niet over? Omdat ze dan een hele hoop gezeik krijgen van klanten waarvan de applicaties ineens niet meer werken. Twee engines (versie 4/5 en versie 6 ofzo) zou idd een optie zijn maar gaat niet echt wat toevoegen aan de performance ben ik bang Als je wat beters wilt kan je beter overstappen op b.v. Ruby(OnRails) of Python met Django b.v.

Ingrijpende veranderingen vind ik prima (als het idd een verbetering is) maar backwards compatibility is wat mij betreft een must. De geintjes die ze tot nu toe geflikt hebben zijn iig niet echt geslaagd, al helemaal niet omdat er nergens gemeld is wat er nou precies veranderd is tussen verschillende versies in.

[GX]

Confusion schreef op zondag 13 november 2005 @ 16:51:
[...]

Wat uitnodigt om elke 2 regels weer eens te compilen om te zien of het zaakje wel compileert, in plaats van goed na te denken over de code en na 20 regels tot je genoegen te merken dat er geen fouten in zitten. Dan duurt het compileren misschien langer, maar uiteindelijk is het toch sneller en heb je beter nagedacht en dus betere code geproduceerd. Werkende code is nog geen goede code.

Vergeet niet dat het hier om PHP gaat en een langere compile-tijd dus eigenlijk alleen maar leidt tot een langzamer script; omdat je PHP niet compiled voor gebruik. Kon dat maar zonder dure zend applicaties.

[NMe]

bartvb schreef op zondag 13 november 2005 @ 18:15:
Dat is leuk en aardig maar daar maak je geen vrienden mee. Ik durf er redelijk wat om te verwedden dat minder dan 10% van de hosters over is op PHP5 en 5 is toch al een flinke tijd uit. Waarom gaan die hosters niet over? Omdat ze dan een hele hoop gezeik krijgen van klanten waarvan de applicaties ineens niet meer werken.

Bullshit. 99% van alle PHP4-apps werken ook in PHP5 nog zonder problemen, tenzij je error_reporting op E_STRICT zet. De reden dat veel hosts nog niet overgestapt zijn is dat de vraag ernaar relatief klein is, aangezien veel applicaties nog gewoon PHP4-compatible zijn en ook nieuwe applicaties vaak nog in PHP4 werken. Daarnaast moeten hosters inderdaad wel testen of een aantal van hun klanten straks hinder ondervindt van de installatie van PHP5, en dat testen kost tijd en geld.

[twiekert]

Confusion schreef op zondag 13 november 2005 @ 18:12:
[...]

Ik vind dat on-the-fly compilen net zo irritant als automatische spellingscorrectie in Word. Belangrijker is de overweging dat als ik het niet goed kan schrijven zonder die hints, dat ik het dan gewoon uberhaupt niet kan. Als doorgewinterde programmeur kan je het rustig aanzetten, maar beginners zouden het zonder moeten doen.

Je zou de Zend IDE eens moeten proberen, een goede IDE zorgt ervoor dat je zoooveel sneller foutloos kan ontwikkelen.

- Duidelijk overzicht van je project & files
- Syntax checking
- Aanvullen van namen van vars, functies classes etc
- Profiler / debugger
- en nog veel meer

Dat on-the-fly compilen (syntax checking dus) is juist hartstikke handig, type fouten haal je er zo uit ipv dat je geconfontreerd wordt met een 'parse error on line xxx' nadat je je file in notepad /editplus bijgewerkt hebt.

GX schreef op zondag 13 november 2005 @ 18:33:
[...]

Vergeet niet dat het hier om PHP gaat en een langere compile-tijd dus eigenlijk alleen maar leidt tot een langzamer script; omdat je PHP niet compiled voor gebruik. Kon dat maar zonder dure zend applicaties.

Vandaag kwam ik de APC compiler tegen op pecl.php.net. Werkt transparant op de achtergrond om je php scripts naar bytecode te compilen en die in het geheugen van de server te bewaren. Als er een bestand opgevraagd wordt, kijkt apc eerst of deze al gecompiled in de memcache staat en serveert die vervolgens, zoniet dan wordt de source php eerst gecompiled

http://pecl.php.net/APC

Ik heb nog geen ervaring met dit pakket maar het ziet er goed uit, en het is nog gratis ook

[Confusion]

twiekert schreef op zondag 13 november 2005 @ 19:43:
Dat on-the-fly compilen (syntax checking dus) is juist hartstikke handig, type fouten haal je er zo uit ipv dat je geconfontreerd wordt met een 'parse error on line xxx' nadat je je file in notepad /editplus bijgewerkt hebt.

Het punt van ACM was in eerste instantie dat compilen te lang duurde, maar dat maakte hij zelf geen goede reden meer (voor het punt dat hij oorspronkelijk in de discussie waar het oorspronkelijk over ging wilde maken) door de mogelijkheid tot on-the-fly compilen te noemen. Mijn reden om een langere compiletijd niet erg te vinden is echter ook een reden om tegen on-the-fly compilen te zijn. Als je het goed foutloos leert te maken, dan ben je minder tijd kwijt met de hele tijd op rode kriebeltjes van de compiler reageren. En als je goed foutloos kan programmeren, dan vraag ik me af of je met of zonder on-the-fly compiler efficienter bent. Maargoed, het is een beetje offtopic.

[ Voor 10% gewijzigd door Confusion op 13-11-2005 20:22 ]

[ACM]

Volgens mij zijn er maar heel weinig mensen die 100% tikfout-vrij kunnen typen. Kun je het wel, dan heb je niks aan die feature, maar biedt die on-the-fly parsing van je source-file ook geen nadelen.
Dus er tegen zijn is tamelijk zinloos dan, want je gebruikt het toch niet

Maak je wel fouten, dan kan het erg handig zijn om er op gewezen te worden dat je iets niet goed doet. Zoals je wellicht weet kunnen (alle grote tegenwoordig?) Java-IDE's tot op zeer hoge niveau's van detaillering controleren of iets wel zou kunnen, terwijl je aan het typen bent of als je er specifiek om vraagt. Als je weinig fouten maakt lijkt het me juist nuttig om niet af en toe te hoeven compileren om te zien of je code zal compileren...
Uiteraard kan je dan alsnog code breken doordat andere files niet meeverandert waren (maar daar heb je refactoring-support voor) en een compilatie-run is dus nog altijd wel een keer nodig.

Het is inderdaad ondertussen wel off-topic.

De syntactisch correcte code is nog altijd niet per se semantisch correct, dus testen zal je het toch wel moeten doen. Mijn punt was dan ook niet zozeer dat het compilen een nadeel is, maar meer dat de tijdswinst van het tijdens de compilatie op fouten gewezen te worden vrij klein is als de compilatie zelf lang duurt.
In diezelfde tijd had je een (unit-)test van je scripting-omgeving gestart kunnen hebben en zou je ongeveer dezelfde informatie gekregen kunnen hebben.

[.oisyn]

ACM schreef op zondag 13 november 2005 @ 10:41:
[...]

Dat is maar een kwestie van wat je cleaner vindt Aangezien je juist meer aandacht moet besteden aan wat voor type iets is, komt er ook per definitie meer code in je applicatie te staan.

1) ik vind een type voor je variabele-initialisatie niet onder meer code vallen, maar soms moet je idd casten ja.
2) om nette php code te schrijven ben je soms zo defensief bezig dat het veel meer code oplevert dan in een strict typed taal.

Het netto verschil is in mijn ogen 0, en dan heb ik liever de voordelen van een strict typed taal.

Klopt, maar moet die waarschuwing per se bij het compileren komen? (Let er op dat de meeste weak-typed talen veel korter compileren) Of mag het ook bij het unit-testen opduiken? Want ook als het niet uitmaakt of het een int of string was krijg je in strong-typed omgevingen een waarschuwing.
Sterker nog, als je een functie overload voor ints en strings en je hebt dus syntactisch correcte code, hoeft dat nog niet te betekenen dat je ook semantisch goede code geschreven hebt. Daar kom je ook alleen maar met (unit-)testing achter.

Nu ben je er weer hele andere dingen bij aan het halen. Ja met een strict typed taal kun je ook fouten maken, wat is je punt precies? Daarnaast hoeft het natuurlijk niet per se gecompileerd te worden, als je per se PHP's manier van interpreteren aan wilt houden zou je ook een tool kunnen maken die een semantische check uitvoert. Het punt is dat de nodige informatie in je code staat, bij weak typed talen niet.

Dat hangt er van af. De standaard containers in java konden tot de introductie van generics al niet gebruikt worden met type-informatie, het enige wat je wist was dat het een object was.
En class-casting kan ook fout gaan, je zou dat zelfs een vorm van weak-typing kunnen noemen.

Dus java is (was) niet perfect. Wat is je punt precies?

Dat is denk ik in veel gevallen helemaal niet zo relevant.

Juist wel, want niemand garandeerd dat jij alle methoden van een interface implementeert, waar een OO taal dat meestal wel forceert.

Je bent wel degelijk sneller klaar als het in de meeste gevallen niet uitmaakt. Voor de aanroep van een toString-methode hoef je niet te weten of iets een Object, een String of whatever is in Java. Het heeft toch wel een toString.

Wederom, wat is je punt? Je bent continu argumenten aan het aanhalen die erover gaan dat je in een strict typed taal soms ook wel eens een weaked type wilt hebben. In C# 2.0 heb je var, in C++ heb je boost::any. In PHP heb je geen keuze. Daarnaast ging mijn hele post om de voordelen van strict typed talen

Niettemin is het wel degelijk deels psychologisch. En ik ben niet de enige die dat vindt, bekende mensen als Bruce Eckel en (volgens hem) Martin Fowler zeggen hetzelfde.

Tja, ik weet niet hoe het met jullie zit maar ik prefereer zelf mijn mening te vormen door de voordelen en nadelen op een rijtje te zetten, en dat tegen elkaar af te wegen aan de hand van een bepaald op te lossen probleem . En mijn eigen ervaring is dat ik het in PHP erg vervelend vind dat type-informatie mist. En natuurlijk zal een mens wel enigszins biased zijn, maar ik mag hopen dat professionals die een mening verkondigen dat ook doen op basis van valide argumenten, en niet omdat ze niet anders kennen.

Als je aan de hand van de type-informatie moet achterhalen wat voor type een object is, moet je wellicht ook wat aan je naamgeving doen

En dat is gewoon te kort door de bocht, en dat weet jij ook wel

Verwijderd schreef op zondag 13 november 2005 @ 13:27:
[...]
Wat een hoop bullshit bij elkaar, waarvan dit toch wel de grootste. Om toString aan te kunnen roepen moet je JUIST weten dat het een Object is. Een primitief type heeft echt geen toString methode.

Blaat, autoboxing.

[ Voor 4% gewijzigd door .oisyn op 14-11-2005 00:55 ]

[.oisyn]

PrisonerOfPain schreef op zondag 13 november 2005 @ 12:57:
[...]

Ik denk veel van dit soort issues, alleen zien de problemen er niet 'onoplosbaar' uit op de een of andere manier. Terwijl dit wel door Zeev aangehaald word als een van de 'conceptuele' redenen om het niet te implementeren.

Pfff allejezus, wat zijn het voor stel klunzen? Het komt allemaal neer op ambiguity, en normale talen geven daar gewoon een error voor. Ik snap niet waarom ze dat niet ook gewoon doen, ipv maar gewoon de eerst-gedefinieerde definitie te pakken wat natuurlijk gewoon vragen is om problemen.

[curry684]

Genoil schreef op zaterdag 12 november 2005 @ 21:20:
[...]

Nee, die komen er helaas niet in. Een of andere Jesse schijnt een patch te hebben ontwikkeld waarmee je het aan kunt zetten, maar zijn werk en die patch wordt vooralsnog genegeerd door het dev team. Na een discussie hier over op de Propel mailinglist is er besloten contact te zoeken met andere grote PHP5 projecten die nut zouden hebben van namespaces met als doel een front te vormen tegenover het dev team om namespaces support alsnog te integreren in een toekomstige release. Ik denk zelf dat dit niet 5.1 zal zijn...

Man, als je dit toch leest dan zet je zo'n produkt toch niet in in een bedrijfsomgeving Is er iemand die kan garanderen dat er op een uniforme bruikbare manier verder wordt ontwikkeld aan PHP of hebben ze echt allemaal een pishekel aan elkaar en zitten ze elkaar zoveel mogelijk dwars met incompatibele patches?

[ACM]

.oisyn schreef op maandag 14 november 2005 @ 00:45:
Nu ben je er weer hele andere dingen bij aan het halen. Ja met een strict typed taal kun je ook fouten maken, wat is je punt precies?

Dat je niet per se méér moeite hoeft te doen om op fouten gewezen te worden, alleen dat je er op een (iets) ander moment op gewezen wordt.

Dus java is (was) niet perfect. Wat is je punt precies?

Dat je de type-informatie lang niet altijd nuttig kunt gebruiken en dus dat het dan overbodig is die erbij te hebben.

Juist wel, want niemand garandeerd dat jij alle methoden van een interface implementeert, waar een OO taal dat meestal wel forceert.

Nou, dan krijg je bij je test vanzelf wel een exception. Uiteraard heeft het voordelen om te weten dat iets gewoon perfect voldoet aan wat je verwacht. Maar de programmeurs schrijven die code natuurlijk ook weer niet at-random en dus lijkt het me lang niet in alle gevallen super noodzakelijk om dat te weten.

Wederom, wat is je punt? Je bent continu argumenten aan het aanhalen die erover gaan dat je in een strict typed taal soms ook wel eens een weaked type wilt hebben.

Ik ben jouw argumenten van tegenvoorbeelden aan het voorzien, ze zijn dan niet ineens minder valide, maar dat zegt nog niet dat weak-typed talen gelijk maar helemaal niks zijn.

Tja, ik weet niet hoe het met jullie zit maar ik prefereer zelf mijn mening te vormen door de voordelen en nadelen op een rijtje te zetten, en dat tegen elkaar af te wegen aan de hand van een bepaald op te lossen probleem .

Uiteraard, je moet er zelf mee werken. Maar anderzijds is het ook wel weer prettig om te weten dat mensen - waarvan gesteld wordt dat ze er verstand van hebben - het met je eens zijn

En mijn eigen ervaring is dat ik het in PHP erg vervelend vind dat type-informatie mist. En natuurlijk zal een mens wel enigszins biased zijn, maar ik mag hopen dat professionals die een mening verkondigen dat ook doen op basis van valide argumenten, en niet omdat ze niet anders kennen.

Deze discussie is natuurlijk gestart met PHP als basis, maar ik denk dat als weak/dynamic-typing goed uitgevoerd wordt de nadelen en voordelen redelijk tegen elkaar opwegen en je terechtkomt bij een "best tool for the job"-situatie.
In webprogramming zit je in erg veel situaties waar je variabele als string aangeleverd wordt en uiteindelijk als string weer weg moet. Waarom dan de moeite nemen dat over en weer te casten als je er toch weinig mee doet?

En dat is gewoon te kort door de bocht, en dat weet jij ook wel

Uiteraard, maar niet eens zo heel veel. Aan de naam van een variabele zou je moeten kunnen zien wat voor type het is. Want er zijn ook zat gevallen waarbij je de initialisatie van een variabele niet meer in beeld hebt, en je dus of uit de naam moet afleiden wat het is (ok, je IDE houdt het voor je bij) of je moet terugbladeren naar de initialisatie.

[Verwijderd]

.oisyn schreef op maandag 14 november 2005 @ 00:45:
Blaat, autoboxing.

Blaat, bullshit.

int a = 3;
a.toString();

[whoami]

Die a.ToString() kan je (in C#) aanroepen, omdat het primitieve type 'int' automatisch gemapped wordt naar het Int32 type (wat een struct is).

[ Voor 3% gewijzigd door whoami op 14-11-2005 10:13 ]

[curry684]

Verwijderd schreef op maandag 14 november 2005 @ 10:08:
[...]

Blaat, bullshit.

int a = 3;
a.toString();

Kerel ben je nou echt zo'n klein kind dat je echt op alles met 'bullshit' moet reageren en alles en iedereen af moet zeiken? Ga anders lekker zelf een forum opzetten waar mensen dat wel normaal vinden?

whoami schreef op maandag 14 november 2005 @ 10:12:
Die a.ToString() kan je (in C#) aanroepen, omdat het primitieve type 'int' automatisch gemapped wordt naar het Int32 type (wat een struct is).

.NET staat deze vorm van autoboxing in iedere taal toe zelfs. Int32 is in principe equivalent aan int en de compiler besluit on the fly of ie van een primitive of een object moet uitgaan.

[ Voor 37% gewijzigd door curry684 op 14-11-2005 10:15 ]

[Verwijderd]

curry684 schreef op maandag 14 november 2005 @ 10:14:
Kerel ben je nou echt zo'n klein kind dat je echt op alles met 'bullshit' moet reageren en alles en iedereen af moet zeiken? Ga anders lekker zelf een forum opzetten waar mensen dat wel normaal vinden?

Ik geef aan aan dat je in java een object nodig hebt om de toString methode over aan te roepen. Dat wordt afgedaan met een "blaat autoboxing". Dat is bullshit, want dat werkt dus niet in Java. Dus zoek dat "kleine kind" even lekker in je eigen moderater ploeg.

[Verwijderd]

We kunnen het php team natuurlijk ook een gedegen management team geven en een goede licentie zodat de helft van alle tegenstrijdige zaken verdwijnen en dat niet iedereen maar even zijn eigen variant implementeert.

Dan zitten er zaken in die niet iedereen leuk vindt maar is het wel uniform. En dat mensen dit liever hebben kunnen we aan Java vs .NET zien.

[ Voor 6% gewijzigd door Verwijderd op 14-11-2005 10:54 ]

[.oisyn]

Verwijderd schreef op maandag 14 november 2005 @ 10:08:
[...]

Blaat, bullshit.

int a = 3;
a.toString();

Ja dat werkt dus in .Net als je van die t een hoofdletter maakt. Dus wat is hier nou bullshit . En als je nu gaat zeggen dat ACM het over java had en dat je slechts daarop reageerde geeft dat alleen maar je eigen onkunde aan om iemand's post als generiek te interpreteren, waar je wel vaker last van schijnt te hebben (ik noem die draad over comments bijvoorbeeld)

[ Voor 34% gewijzigd door .oisyn op 14-11-2005 11:29 ]

[.oisyn]

ACM schreef op maandag 14 november 2005 @ 07:36:
[...]

Dat je niet per se méér moeite hoeft te doen om op fouten gewezen te worden, alleen dat je er op een (iets) ander moment op gewezen wordt.

Nou ja mijn punt was meer dat je er in PHP vaak helemaal niet op gewezen wordt zonder daar zelf echt moeite voor te doen .

Dat je de type-informatie lang niet altijd nuttig kunt gebruiken en dus dat het dan overbodig is die erbij te hebben.

Tja, ik vind de oude java containers (waar we het over hadden) net zo vervelend als php moet ik zeggen . Máár je krijgt wel meteen een error als je naar het verkeerde type cast, in PHP kan zo'n probleem zich pas veel later voordoen als je uiteindelijk een methode aanroept die niet blijkt te bestaan. Het is dan soms wat lastig om erachter te komen waar die fout er ingeslopen is.

Ik ben jouw argumenten van tegenvoorbeelden aan het voorzien, ze zijn dan niet ineens minder valide, maar dat zegt nog niet dat weak-typed talen gelijk maar helemaal niks zijn.

Maar ik heb nooit gezegd dat ik weak types helemaal niets vind . Daarom zei ik al, ik heb die keuze liever zelf; talen als C++, VB en C# 2 zijn strong typed maar hebben wel een variabel type (ok, in C++ wordt het natuurlijk niet native ondersteund maar het is goed te implementeren met de bestaande features)

In PHP heb je echter nergens de keuze, en op sommige punten werkt dat best kut.

Uiteraard, maar niet eens zo heel veel. Aan de naam van een variabele zou je moeten kunnen zien wat voor type het is.

Als je hungarian notitie gebruikt ja. Natuurlijk, soms kun je aan de naam/context zien wat het moet zijn, maar soms ook niet. Daarnaast, om het IDE punt aan te houden, kan je IDE je van code completion voorzien.

[curry684]

.oisyn schreef op maandag 14 november 2005 @ 11:47:
[...]

Maar ik heb nooit gezegd dat ik weak types helemaal niets vind . Daarom zei ik al, ik heb die keuze liever zelf; talen als C++, VB en C# 2 zijn strong typed maar hebben wel een variabel type (ok, in C++ wordt het natuurlijk niet native ondersteund maar het is goed te implementeren met de bestaande features)

C# een variabel type? Als je op de var doelt die in de specificaties voor 3.0 zit, dat is geen variant in de betekenis van weak typing. Een var mag je namelijk alleen declareren inclusief een assignment:

C#:

var myval = 42;

Dit kun je het beste omschrijven als 'implicit strong typing', omdat myval nu wel degelijk van het type int is. Ter vergelijking zou je myval ook als object kunnen declareren, waarmee je weak typing een stuk beter benadert... behalve dat object natuurlijk geen methodes van derivants ondersteunt zonder terugcasten. Zie deze code:

C#:

var myval = 42;
object myobj = 42;
myval += 42;  // Geldig, want myval is een System.Int32
myobj += 42;  // Ongeldig, want object heeft geen operator+=(System.Int32)

De uitleg:

Local variables in C# are statically typed. C# 3.0 doesn't change this. The only thing that var changes is that you don't have to declare the type explicitly - the compiler infers the variable's type. Specifically, the variable's type will be whatever type its initialization expression is. (An uninitialized var will cause a compiler error.) For example, our ivar variable above was initialized with the expression 42. That's an integer literal, so the expression's type is System.Int32, which in turn means that ivar's type is System.Int32. The compiler worked out the type for itself, but it's still statically typed. It's as though we had just declared the variable as an int.

Wat is nu het nut ervan? Allereerst readability:

C#:

Dictionary<string, Control> d = new Dictionary<string, Control>();

Is syntactisch hetzelfde als het veel prettiger leesbare:

C#:

var d = new Dictionary<string, Control>();

Maar de echte reden zit in anonymous types die zonder var niet zouden kunnen:

The real reason var was added is so that we can declare a strongly typed variable without needing to know the name of the variable's type. This is required in order to enable another new C# 3.0 language feature: anonymous types. You wouldn't be able to declare a variable of an anonymous type if you always had to include the type name as part of the variable declaration. That's the main reason var has been added to the language.

var is dus geen variant, en C# kent geen weak typing, ook niet optioneel

Voor anonymous types, zie deze korte doch heldere blogpost.

[.oisyn]

Ah ok, de auto variant van C++0x dus

[Olaf van der Spek]

-NMe- schreef op zaterdag 12 november 2005 @ 21:28:
Je gaat je toch afvragen wat een developersteam zulke keuzes laat maken.

Van een 'team' dat een crash van de PHP engine beschouwt als not-a-bug zou ik niet teveel verwachten.

Mijn IP adres werd trouwens gebanned (door Derick) na een discussie over dit soort bugs van qa.php.net. Ik denk dat dat ook wel iets zegt over de 'professionaliteit'.

[ Voor 26% gewijzigd door Olaf van der Spek op 14-11-2005 13:25 ]

[Verwijderd]

.oisyn schreef op maandag 14 november 2005 @ 11:26:
Ja dat werkt dus in .Net als je van die t een hoofdletter maakt. Dus wat is hier nou bullshit . En als je nu gaat zeggen dat ACM het over java had en dat je slechts daarop reageerde geeft dat alleen maar je eigen onkunde aan om iemand's post als generiek te interpreteren, waar je wel vaker last van schijnt te hebben (ik noem die draad over comments bijvoorbeeld)

Ik reageerde slechts op java want daar had ACM het nou eenmaal over. En probeer je nu eens wat minder kinderachtig op te stellen.

[curry684]

In C# kun je overigens bij gebrek aan union in principe ook geen variant zelf implementeren, maar daar is wel omheen te werken

Blijft de vraag overigens waarom je in een taal die zo expliciet strong typed is terug zou willen vallen op weak typing: alle gevallen waar ik ooit in C/C++ unions heb gebruikt zou ik in C# oplossen met een class-tree.

[.oisyn]

curry684 schreef op maandag 14 november 2005 @ 13:06:
In C# kun je overigens bij gebrek aan union in principe ook geen variant zelf implementeren, maar daar is wel omheen te werken

Waar heb je een union voor nodig, je hebt toch gewoon Object? Native types kunnen ook gewoon auto-boxed worden naar Object. boost::any in C++ doet min of meer hetzelfde door een referentie naar een accessor interface bij te houden, die mbv templates voor elk type geimplementeerd is.

Blijft de vraag overigens waarom je in een taal die zo expliciet strong typed is terug zou willen vallen op weak typing: alle gevallen waar ik ooit in C/C++ unions heb gebruikt zou ik in C# oplossen met een class-tree.

unions zijn lelijk, bovendien kun je types met een gedefinieerde ctor/dtor niet in een union stoppen.

[.oisyn]

Verwijderd schreef op maandag 14 november 2005 @ 13:01:
[...]
Ik reageerde slechts op java want daar had ACM het nou eenmaal over. En probeer je nu eens wat minder kinderachtig op te stellen.

Reageer dan niet zo selectief en buiten context. Daarnaast is iedereen maar kinderachtig noemen ook nou niet bepaald professioneel.

[curry684]

.oisyn schreef op maandag 14 november 2005 @ 13:15:
[...]

Waar heb je een union voor nodig, je hebt toch gewoon Object?

Unions zijn tig keer performanter. Maar zoals ik al zeg boeien ze buiten de tijdskritische C++ apps niet en zijn er veel betere oplossingen

[Olaf van der Spek]

-NMe- schreef op zondag 13 november 2005 @ 13:55:
Het zal even snel zijn; PHP moet zelf immers ook intern gaan casten. Ook in PHP zal bijvoorbeeld een string intern gewoon een array van chars zijn, afgesloten met een \0.

Strings zijn (AFAIK) binary-safe in PHP, dus ik gok dat ze niet null-terminated zijn. Null-termination heeft tegenwoordig toch ook geen voordeel meer ten opzichte van een extra length variable?

[Olaf van der Spek]

Confusion schreef op zondag 13 november 2005 @ 16:51:
Wat uitnodigt om elke 2 regels weer eens te compilen om te zien of het zaakje wel compileert, in plaats van goed na te denken over de code en na 20 regels tot je genoegen te merken dat er geen fouten in zitten. Dan duurt het compileren misschien langer, maar uiteindelijk is het toch sneller en heb je beter nagedacht en dus betere code geproduceerd. Werkende code is nog geen goede code.

Is compile duration voor C++ nog steeds een issue? Met background compiling op moderne CPUs zou het toch, zeker als je geen headers wijzigt, toch niet meer uit moeten maken?

[Verwijderd]

Kan iemand mij uitleggen waarom je al die wijzigingen zou willen hebben in PHP. PHP is juist populair geworden door de eenvoud. Deze discussie heb ik een tijdje geleden ook al gezien bij CF, waar dus ook steeds meer functionaliteiten zijn toegevoegd zodat er encapsulation, inheritance, etc. bereikt kon worden. Daaruit kwam ook al de conclusie, het is wat het is, en daarom is het zo groot geworden.

Als je aan dergelijke functionaliteit toe bent, waarom zou je dan niet gewoon naar een omgeving gaan die dat daadwerkelijk van origine biedt.

[Olaf van der Spek]

Verwijderd schreef op maandag 14 november 2005 @ 13:31:
PHP is juist populair geworden door de eenvoud.

Dat is de grote vraag. Welke eenvoud precies?
Een belangrijke reden is denk ik dat voor het installeren van een PHP script geen shell access nodig is.
Dat heeft echter weinig tot niets met de eenvoud van de taal zelf te maken.

[Verwijderd]

OlafvdSpek schreef op maandag 14 november 2005 @ 14:01:
[...]

Dat is de grote vraag. Welke eenvoud precies?
Een belangrijke reden is denk ik dat voor het installeren van een PHP script geen shell access nodig is.
Dat heeft echter weinig tot niets met de eenvoud van de taal zelf te maken.

Het niet hoeven na te denken over namespaces, object models, hierarchie en inheritance, interfaces, access modifiers, en paradigma's als layers en encapsulation...

PHP is toch vooral populair geworden als procedural language, van boven naar beneden je scripting uitvoeren en klaar.

[Olaf van der Spek]

Verwijderd schreef op maandag 14 november 2005 @ 14:14:
Het niet hoeven na te denken over namespaces, object models, hierarchie en inheritance, interfaces, access modifiers, en paradigma's als layers en encapsulation...

PHP is toch vooral populair geworden als procedural language, van boven naar beneden je scripting uitvoeren en klaar.

In de meeste andere talen kun je al die zaken toch ook links laten liggen en hetzelfde doen als je in PHP doet?

[curry684]

Zelfs in ASP.NET kun je het hele concept code-behind negeren en je aspx puur uit procedurele (!!!) C# bouwen. Dan heb je PHP met typesafety en een cleane syntax

[Verwijderd]

OlafvdSpek schreef op maandag 14 november 2005 @ 14:18:
[...]

In de meeste andere talen kun je al die zaken toch ook links laten liggen en hetzelfde doen als je in PHP doet?

Het verschil met die talen is, is dat ze je direct al sturen in een pure OO richting waar je dergelijke zaken allemaal aantreft. Dat is iets wat PHP nooit heeft gedaan en nu dan ineens wel zou moeten doen. Je kunt in C# ook procedureel alles opbouwen, maar dat is niet de opzet van ASP.NET.

Nu is het toevoegen van strong typing in een dynamische taal al helemaal complex zelfs voor de echte talenten zonder het breken van backwards compatibility, dus waarom zou je uberhaupt gaan proberen om van PHP een 2de Java/.NET te maken.

Dezelfde discussie maar dan met betrekking tot CF liep ook hier:
http://clearsoftware.net/...081-2BAC-69BDEDC4F391A514

[ Voor 10% gewijzigd door Verwijderd op 14-11-2005 14:30 ]

[.oisyn]

Het gaat er helemaal niet om dat het helemaal OO gemaakt wordt, de procedurele insteek en de freeform statements (code buiten functies) kan gewoon aangehouden worden. Waar het om gaat is dat het hele zooitje nou eens opgeschoond wordt en alle inconsistencies weggewerkt worden, zowel in de taal als in de standard library.

[NMe]

OlafvdSpek schreef op maandag 14 november 2005 @ 13:22:
Strings zijn (AFAIK) binary-safe in PHP, dus ik gok dat ze niet null-terminated zijn. Null-termination heeft tegenwoordig toch ook geen voordeel meer ten opzichte van een extra length variable?

Null-terminated strings kunnen in principe zo lang worden als je wil, terwijl er met een extra length-veld een limiet is die even groot is als het aantal bits dat dat length-veld bestrijkt. Nou zal dat in de gemiddelde taal geen probleem zijn, maar in PHP werk je over het algemeen veel met strings, dus die kunnen ook wel eens aardig lang worden.

Overigens is het best mogelijk dat ze intern gebruik maken van een length-veld. Ik ben er nooit ingedoken om dat uit te vinden, aangezien dat soort dingen niet echt relevant zijn voor mij als scripter.

OlafvdSpek schreef op maandag 14 november 2005 @ 13:01:
Van een 'team' dat een crash van de PHP engine beschouwt als not-a-bug zou ik niet teveel verwachten.

Ik verwacht sowieso al niet al teveel van dat team, maar je zou toch zeggen dat er iets van logica zit in hun gedachtengang. Ik ben benieuwd welke.

Mijn IP adres werd trouwens gebanned (door Derick) na een discussie over dit soort bugs van qa.php.net. Ik denk dat dat ook wel iets zegt over de 'professionaliteit'.

Gewoon uit interesse, dus niet als verwijt: ging de discussie er verhit aan toe? Of konden ze gewoon geen gelijk krijgen?

[Olaf van der Spek]

-NMe- schreef op maandag 14 november 2005 @ 15:20:
Null-terminated strings kunnen in principe zo lang worden als je wil, terwijl er met een extra length-veld een limiet is die even groot is als het aantal bits dat dat length-veld bestrijkt. Nou zal dat in de gemiddelde taal geen probleem zijn, maar in PHP werk je over het algemeen veel met strings, dus die kunnen ook wel eens aardig lang worden.

Eh, met een standaard 32-bit int kun je strings tot 2/4 gbyte ondersteunen. Zou dat niet genoeg zijn?

Gewoon uit interesse, dus niet als verwijt: ging de discussie er verhit aan toe? Of konden ze gewoon geen gelijk krijgen?

http://bugs.php.net/bug.php?id=30153
http://bugs.php.net/bug.php?id=30881

Een van die twee moet het zijn. Verhit? Totaal niet volgens mij.

[koli-man]

.oisyn schreef op maandag 14 november 2005 @ 14:52:
Waar het om gaat is dat het hele zooitje nou eens opgeschoond wordt en alle inconsistencies weggewerkt worden, zowel in de taal als in de standard library.

En ik ben van mening als je applicaties cq websites hebt gemaakt met de meest gebruikte en triviale functies van PHP4, het geen problemen moet opleveren met opschonen. Ik denk dat het pas echt problemen gaat opleveren als je altijd de meest nieuwe functies hebt gebruikt, die misschien nog aan verandering onderhevig kunnen zijn.

[.oisyn]

koli-man: eigenlijk wel, het huidige references systeem moet imho substantieel veranderd worden waardoor oude code breekt. Evenals alle scope issues.

[Verwijderd]

Voor de geinteresseerden, een artikel over het toevoegen van optional static typing in Python en de problemen daarbij

http://www.artima.com/weblogs/viewpost.jsp?thread=85551

[Verwijderd]

Iedereen zit te praten over hoe PHP wel niet verandert moet worden naar een meer C#/Java achtige taal (volledig mee eens overig). Maar is het niet juist de sterkte van php dat je beetje rommelig dingen kunt opbouwen? PHP 6 met een hoop veranderingen zal toch niet snel geaccepteerd worden door de markt. Kun je dan niet beter werken aan de acceptatie van een andere scripting taal zoals ruby of phyton?

[ Voor 4% gewijzigd door Verwijderd op 14-11-2005 16:39 ]

[Koeniepoenie]

Verwijderd schreef op maandag 14 november 2005 @ 16:38:
Iedereen zit te praten over hoe PHP wel niet verandert moet worden naar een meer C#/Java achtige taal (volledig mee eens overig). Maar is het niet juist de sterkte van php dat je beetje rommelig dingen kunt opbouwen?

Hoe zou de rommeligheid van een taal nu de taal sterk kunnen maken? De lage leerdrempel heeft er wel voor gezorgd dat het populair werd bij het grote publiek.

PHP 6 met een hoop veranderingen zal toch niet snel geaccepteerd worden door de markt. Kun je dan niet beter werken aan de acceptatie van een andere scripting taal zoals ruby of phyton?

Dit zeg je wel erg makkelijk.. Omdat een taal "waarschijnlijk" niet snel geaccepteerd zou worden op de markt zouden we er maar helemaal geen aandacht aan moeten besteden. Ik vraag me trouwens ook af waarom PHP6 niet snel geaccepteerd zou worden Ik heb nog nergens concrete plannen gezien (op een wishlist na dan), laat staan plannen die de hele taal om zouden gooien

[Verwijderd]

Maar ik vraag me af, waarom zou je nog PHP willen gebruiken als je schijnbaar op een dermate kennisniveau zit dat je met een echte OO omgeving als ASP.NET of Java hetzelfde en nog wel meer kunt bereiken. Ik volg de gedachtengang achter die verandering niet eerlijk gezegd

[Verwijderd]

OlafvdSpek schreef op maandag 14 november 2005 @ 15:44:
[...]

http://bugs.php.net/bug.php?id=30153
http://bugs.php.net/bug.php?id=30881

Een van die twee moet het zijn. Verhit? Totaal niet volgens mij.

Beide zijn officieel een bug.

It is a problem. Marking it suspended instead. The solution is
non-trivial. If you have one, please let us know.

en

This bug has been fixed in the documentation's XML sources

Maar wat wel raar is, is dat je a) heel veel moeite moet doen om de mensen die het beheer doen zo gek te krijgen dat ze begrijpen wat het probleem is en b) dat beide gevallen niet opgelost worden.
Integendeel, bij het eerste doen ze gewoon niets (waardoor je een server met fileupload mogelijkheden (en gzip) dus kan laten crashen ) en bij de tweede passen ze de documentatie aan zodat het non-standaard gedrag van PHP opeens "standaard" wordt. Als de documentatie overeen zou komen met het functionele ontwerp zou dat natuurlijk de omgekeerde wereld zijn.

Al met al is dus niet echt hoe ik zou willen hoe men op mijn bugreports reageert. Aan de andere kant is PHP een Open Source product. Gebruikers kunnen daarbij meewerken aan een oplossing voor de bugs die ze tegenkomen. Een houding van: "Ik heb een bug. Los het voor mij op" is dan ook minder op zijn plaats dan bij bv Microsoft. Zeker bij het eerste probleem lijkt een eigen patch een reële mogelijkheid.

Ook zegt de kwaliteit van de bugafhandeling niet direct iets over de kwaliteit van het product. Een verband tussen de bugafhandeling en de introductie van nieuwe concepten in de taal zie ik dus niet. Het kan best zijn dat er goede redenen zijn om geen strong typing in de taal op te willen nemen. Maar vraag mij niet wat die reden zou moeten zijn.

[paulh]

Ik zou strong typing heerlijk vinden in PHP ... dan kan er eindelijk eens een ide gemaakt worden die compiler checks voor je doet. Zo heb je bijvoorbeeld in Eclipse (voor java) de controle op al je classes en hoe ze onderling van elkaar afhankelijk zijn. Dus als je ergens iets wijzigt kan je meteen zien of er ergens anders iets omvalt. Zolang een project niet al te omvangrijk is vind ik PHP echt superhandig maar refactoren in PHP is echt zo zwaar waardeloos.

[Gomez12]

Ach tja, weak typing. In het begin lijkt het zo leuk ( gewoon een int even in een string echo-en en daarna weer verderwerken met dezelfde int ) Maar na verloop van tijd is het mij zo gaan tegenstaan.

Altijd leuk om iets te definieren als int, dus niets anders dan getallen mag in deze variabele staan, gooi je je variabele rechtstreeks in een sql heb je ineens een sql-exploit, waarvandaan??? Ohja natuurlijk, je hebt niet gecontroleerd of de variabele die je als integer benoemd hebt ook nog steeds wel integer is....
Zelfde met int's en floats, jarenlang een nette afronding kunnen maken door een int *,5 te doen, maar met php is in mijn variabele opeens veranderd naar een float???

Alhoewel het veels te veel gevraagd is om php direct strongtyping te maken( 100% van de bestaande scripts breekt ongeveer ). Zou een script-directive voor strong-typing wel erg aangenaam zijn.

En wat iemand hierboven zegt over dat je alleen maar met strings (I/O) werkt op inet, dit klopt wel, maar sinds ze de $GET etc array's standaard hebben gemaakt moet je toch al je input check of je moet gewoon stomzinnig je $GET array nu rechtstreeks als variabelen gaan gebruiken. Dus ze kunnen het wel doen ( strong typing, want een aparte array's voor input vind ik gewoon een halfzachte poging tot strong typing aan de input kant, je moet de array toch omzetten, dus een beetje casting kan er dan ook nog wel bij ).

Weak typing kan zo af en toe best makkelijk zijn, maar als je je als prog-taal al op beginners richt creeer je met weak typing meer schade dan waarde ( ik wil niet eens beginnen te tellen voor scripts waarbij op regel 500 eventjes spontaan een variabele genoemd en gevuld wordt die ik voor de rest nergens meer terugzie, en dan later denken, oh die variabele is ter plekke aangemaakt en gevuld, nee geef me dan toch maar een prog waarbij in het begin alle variabele declaraties staan, zodat ik 1 plek waarin ik iets hoef op te zoeken )

[curry684]

Verwijderd schreef op maandag 14 november 2005 @ 19:44:
Maar ik vraag me af, waarom zou je nog PHP willen gebruiken als je schijnbaar op een dermate kennisniveau zit dat je met een echte OO omgeving als ASP.NET of Java hetzelfde en nog wel meer kunt bereiken. Ik volg de gedachtengang achter die verandering niet eerlijk gezegd

Omdat je PHP+MySQL hosting voor een appel en een ei kunt krijgen, bijna gratis bij een pak melk?

Als ASP.NET+SQL Server hosting net zo cheap en common was zou ik nooit geen regel PHP meer aanraken hoor

[ACM]

Gomez12 schreef op maandag 14 november 2005 @ 22:17:
Altijd leuk om iets te definieren als int, dus niets anders dan getallen mag in deze variabele staan, gooi je je variabele rechtstreeks in een sql heb je ineens een sql-exploit, waarvandaan??? Ohja natuurlijk, je hebt niet gecontroleerd of de variabele die je als integer benoemd hebt ook nog steeds wel integer is....

Dan had je wel een waarde 'van buiten' aan die variabele gekoppeld. Bij je strong-typed taal moet je dan trouwens ook nog steeds checken of het wel in orde is, want vaak is een negatief getal of 0 ook niet valide. Je bent gewoon altijd min of meer verplicht die invoer van gebruikers te checken. Dat je daar dan bij weak-typed omgevingen nog net iets anders tegenaan moet kijken... ach, dat is weinig extra werk in die gevallen lijkt me.

Zelfde met int's en floats, jarenlang een nette afronding kunnen maken door een int *,5 te doen, maar met php is in mijn variabele opeens veranderd naar een float???

Nette afronding? Ik vind dergelijke "hacks" tamelijk vies eerlijk gezegd Ik moet eerlijk zeggen dat ik dat hacky gedrag nu voor het eerst zie als afrondings manier, maar dat zal wel komen omdat ik nooit serieus in C gewerkt heb.
In Java is er de Math.round() en in diverse andere talen iets soortgelijks. Kan je ook nog eens beter definieren wat er moet gebeuren (bankers' rounding bijv) in "corner cases".

En wat iemand hierboven zegt over dat je alleen maar met strings (I/O) werkt op inet, dit klopt wel, maar sinds ze de $GET etc array's standaard hebben gemaakt moet je toch al je input check of je moet gewoon stomzinnig je $GET array nu rechtstreeks als variabelen gaan gebruiken. Dus ze kunnen het wel doen ( strong typing, want een aparte array's voor input vind ik gewoon een halfzachte poging tot strong typing aan de input kant, je moet de array toch omzetten, dus een beetje casting kan er dan ook nog wel bij ).

Die super-global arrays hebben niks met typing te maken. Enkel met scoping. Wat je vast weet, maar om compleet te zijn: "Vroeger" werden de variabelen uit de request-omgeving gewoon rechtstreeks in de globale scope van je php-omgeving gemikt. Als je bijv een waarde niet initialiseerde en wel ongetest gebruikte, kon dat vervelende dingen opleveren.

nee geef me dan toch maar een prog waarbij in het begin alle variabele declaraties staan, zodat ik 1 plek waarin ik iets hoef op te zoeken )

In Java is dat ook nooit verplicht geweest, C is de enige van (nog steeds veel gebruikte) de talen die ik redelijk tot goed ken die dat vereist... Ik vind dat eerlijk gezegd een beetje een onhandige eis. Want het verplicht je ook tijdelijke variabelen vooraan te mikken, terwijl je die juist alleen in bijvoorbeeld een do-while gebruikt.
Dan lijkt het mij juist onhandig dat de declaratie er zover vandaan staat.
Overigens is dat weer iets heel anders en is imho vooral een geval van "Code Conventions" opvolgen.

't Heeft overigens ook mijn voorkeur om waar logisch en mogelijk de declaratie aan het begin van je nieuwe scope te hebben. Maar no-way dat ik zoiets zou willen:

C:

int test() {
   int i;
/* 20 regels code*/
  for(i = 0; i < ...; i++)
  { /* ... */  }
}

Doe me dan maar de java-style for-loops

[curry684]

ACM schreef op maandag 14 november 2005 @ 22:54:
[...]

Nette afronding? Ik vind dergelijke "hacks" tamelijk vies eerlijk gezegd Ik moet eerlijk zeggen dat ik dat hacky gedrag nu voor het eerst zie als afrondings manier, maar dat zal wel komen omdat ik nooit serieus in C gewerkt heb.
In Java is er de Math.round() en in diverse andere talen iets soortgelijks. Kan je ook nog eens beter definieren wat er moet gebeuren (bankers' rounding bijv) in "corner cases".

In C heb je daarvoor ceil(...), floor(...) en round(...) in math.h slingeren.

[ripexx]

curry684 schreef op maandag 14 november 2005 @ 22:44:
[...]
Omdat je PHP+MySQL hosting voor een appel en een ei kunt krijgen, bijna gratis bij een pak melk?

Als ASP.NET+SQL Server hosting net zo cheap en common was zou ik nooit geen regel PHP meer aanraken hoor

Tja als je als hoster IIS en SQL server wil aanbieden ben je behoorlijk wat kwijt aan licenties en dat moet gewoon betaald worden. Ik denk dat zodra de combi .net & sql server net zoveel kost als een php mysql combi de populariteit van .Net en SQL server onder de hobbisten een stuk groter is. Maar volgens mij zit Microsoft niet echt op dit soort werk te wachten. De professionele markt weet dit beter op waarde te schatten. Al met al is het het gewoon appels met peren vergelijken. Mede door het opensource karakter is het gewoon heel lastig om er iets van te maken. Want er zijn gewoon te veel meningen en er is niet iemand die de grote lijnen uitzet.

Ach wie weet neemt Google een paar developers aan en maakt er nog wat moois van In ieder geval voldoet PHP prima voor mijn hobby website.

[Confusion]

ACM schreef op maandag 14 november 2005 @ 22:54:
Nette afronding? Ik vind dergelijke "hacks" tamelijk vies eerlijk gezegd Ik moet eerlijk zeggen dat ik dat hacky gedrag nu voor het eerst zie als afrondings manier, maar dat zal wel komen omdat ik nooit serieus in C gewerkt heb.
In Java is er de Math.round() en in diverse andere talen iets soortgelijks. Kan je ook nog eens beter definieren wat er moet gebeuren (bankers' rounding bijv) in "corner cases".

Java gebruikt een C Math library voor de belangrijkste Math functions (API van StrictMath):

To help ensure portability of Java programs, the definitions of some of the numeric functions in this package require that they produce the same results as certain published algorithms. These algorithms are available from the well-known network library netlib as the package "Freely Distributable Math Library," fdlibm. These algorithms, which are written in the C programming language, are then to be understood as executed with all floating-point operations following the rules of Java floating-point arithmetic.

Dit om aan de IEEE 754 specs te voldoen. Math.round() roept Math.floor() aan, die roept StrictMath.floor() aan en die gaat naar een native functie van de genoemde lib.

[ Voor 7% gewijzigd door Confusion op 15-11-2005 09:07 ]

[Olaf van der Spek]

Verwijderd schreef op maandag 14 november 2005 @ 20:40:
Al met al is dus niet echt hoe ik zou willen hoe men op mijn bugreports reageert. Aan de andere kant is PHP een Open Source product. Gebruikers kunnen daarbij meewerken aan een oplossing voor de bugs die ze tegenkomen.

Natuurlijk, maar als de auteurs direct zeggen dat het geen bug is begin ik natuurlijk niet eens aan een patch. Ik eis ook geen oplossing.
Verder verschilt het heel erg per open source project. Met bepaalde Debian packages en MySQL heb ik bijvoorbeeld betere ervaringen.

Een houding van: "Ik heb een bug. Los het voor mij op" is dan ook minder op zijn plaats dan bij bv Microsoft. Zeker bij het eerste probleem lijkt een eigen patch een reële mogelijkheid.

[ACM]

Confusion schreef op dinsdag 15 november 2005 @ 09:06:
[...]

Java gebruikt een C Math library voor de belangrijkste Math functions (API van StrictMath):

[...]

Dit om aan de IEEE 754 specs te voldoen. Math.round() roept Math.floor() aan, die roept StrictMath.floor() aan en die gaat naar een native functie van de genoemde lib.

En wat probeer je daarmee duidelijk te maken? Mijn punt is dat er een library-functie voor bestaat, en het imho over het algemeen aanbevolen is die library-functie te gebruiken (code-reuse enzo). Of dat nou op de achtergrond een native-lib aanroept of niet is totaal niet relevant voor jou als gebruiker.
Hooguit als je in termen van micro-optimalisaties per se de boel supersnel moet hebben.

[.oisyn]

ACM schreef op maandag 14 november 2005 @ 22:54:
In Java is dat ook nooit verplicht geweest, C is de enige van (nog steeds veel gebruikte) de talen die ik redelijk tot goed ken die dat vereist...

Ook in C is het niet meer verplicht sinds 1999

[aex351]

Wat ik wel in toekomstige versies van PHP zou willen hebben is de mogelijkheid dat er meer met haakjes gewerkt zou kunnen worden. Zie ook onderstaand voorbeeld. Voor zover ik weet is dit nog niet mogelijk.

PHP:

if ( ( isset($a) || isset($b) ) && (  $c == '2') ) { echo ' exec' ; }

[ Voor 7% gewijzigd door aex351 op 16-11-2005 01:52 ]

[Exirion]

Verwijderd schreef op maandag 14 november 2005 @ 19:44:
Maar ik vraag me af, waarom zou je nog PHP willen gebruiken als je schijnbaar op een dermate kennisniveau zit dat je met een echte OO omgeving als ASP.NET of Java hetzelfde en nog wel meer kunt bereiken. Ik volg de gedachtengang achter die verandering niet eerlijk gezegd

I second that. Mensen die helemaal gek zijn van een bepaalde taal/omgeving die in de loop der tijd steeds meer wordt verkracht om alles te kunnen wat andere talen/omgevingen al lang konden. Zoiets als Visual Basic dat in de loop der jaren letterlijk is verkracht om iets *kuch* fatsoenlijks *kuch* te worden dat enigszins kan concurreren met Delphi/C++Builder/VisualC++. Het blijft gewoon een kuttaal in een kutomgeving.

[NMe]

aex351 schreef op woensdag 16 november 2005 @ 01:51:
Wat ik wel in toekomstige versies van PHP zou willen hebben is de mogelijkheid dat er meer met haakjes gewerkt zou kunnen worden. Zie ook onderstaand voorbeeld. Voor zover ik weet is dit nog niet mogelijk.

PHP:

if ( ( isset($a) || isset($b) ) && (  $c == '2') ) { echo ' exec' ; }

Tuurlijk is dat wel mogelijk? Je kan zoveel haakjes gebruiken als je wil hoor.

Exirion schreef op woensdag 16 november 2005 @ 01:55:
I second that. Mensen die helemaal gek zijn van een bepaalde taal/omgeving die in de loop der tijd steeds meer wordt verkracht om alles te kunnen wat andere talen/omgevingen al lang konden. Zoiets als Visual Basic dat in de loop der jaren letterlijk is verkracht om iets *kuch* fatsoenlijks *kuch* te worden dat enigszins kan concurreren met Delphi/C++Builder/VisualC++. Het blijft gewoon een kuttaal in een kutomgeving.

Wat betreft VB moet ik je gelijk geven, in elk geval tot en met versie 6. Over VB.NET kan ik geen uitspraken doen, want daar heb ik nooit mee gewerkt. Maar wat betreft PHP: dat zou best een aardige taal zijn, als ze nu eens eindelijk de grote tekortkomingen eruit werken, desnoods ten koste van de portabiliteit van oude scripts. Hosts vinden daar wel een oplossing voor, bijvoorbeeld PHP5 en PHP6 naast elkaar draaien. Of desnoods zouden ze kunnen stoppen met de ontwikkeling van PHP, en een aftakking kunnen maken in een nieuw project, gebaseerd op dezelfde principes, dat ze wel fatsoenlijk opzetten.

Voor mij begint PHP steeds minder interessant te worden, maar zolang webhosts vaker PHP ondersteunen dan ASP.NET of een andere serverside taal is de keuze voor mij snel genoeg gemaakt.

[ Voor 58% gewijzigd door NMe op 16-11-2005 02:18 ]