[PHP 5.0.0] Final release!

[Verwijderd]

Ik krijg de volgende error:

Time-out van CGI
De opgegeven CGI-toepassing heeft de toegestane tijdsduur overschreden. De server heeft het proces verwijderd.

Dit bij het oproepen van een simpele php pagina...


Ik heb PHP5 geinstalleerd, de php.ini juist geconfigureerd zoals is aangegeven, de verschillende extensies ge-enabled en ook de .php extensie in IIS aan php-cgi.exe gekoppeld...

Wat doe ik fout?

[Verwijderd]

Soultaker schreef op 14 juli 2004 @ 02:17:
Mooie nieuwe features, als ik het zo zie. Het object oriented gebeuren vind ik niet heel interessant (op de bugfixes t.o.v. PHP4 na), maar XML integratie en bundeling met SOAP lijken me allebei sterke punten.

OO was misschien nodig, *ooit*. Ze hadden beter andere dingen kunnen ontwikkelen zodat ze daadwerkelijk hun marktaandeel behouden. Dingen als XML integratie/SOAP zijn leuk, maar *heel erg mager* voor een major update.

Je toespitsen op zaken als PHP aanroepbaar maken vanaf de commandline: hallo waar gaat dat nog om?

OO boeit nauwelijks; je gaat toch eigenlijk geen uitgebreide OO structuur opbouwen en objecten inlezen bij elke pagina aanroep. Het moest verbeterd worden, maar het is niet de Grote Update waar de webdev-wereld op zat te wachten.

Ze hadden er veel meer dingen in moeten stoppen zodat de development van webapps naar een nieuw niveau wordt getilt: dingen als interactie met het DOM model, abstractie van het pagina's opbouwen (een windowing toolkit iemand? waar blijven die libs in standaard PHP?) abstractie over de page generation/page request cyclus zijn zoveel meer waard als een gerepareerd OO model.

Als ze zo blijven steken als nu, gaan ze verliezen van bijvoorbeeld ASP en ASP.NET. Ze zitten zo dicht op hun eigen produkt dat ze de grote lijnen niet meer zien.

Wat is er bekend over backward compatibility? Is het zinnig om PHP4 te vervangen door PHP5 zonder dat bestaande scripts kapot gaan? Is het mogelijk om op PHP5 te ontwikkelen en de scripts (zonder PHP5-specifieke features, natuurlijk) vervolgens op een PHP4 server te draaien?

PHP weet in minor versions upgrade ook al backward compatibility te breken (is nu al meerdere malen gebeurd), dus ik vrees het ergste in de praktijk.

[Verwijderd]

Verwijderd schreef op 29 september 2004 @ 15:57:
[...]

OO was misschien nodig, *ooit*. Ze hadden beter andere dingen kunnen ontwikkelen zodat ze daadwerkelijk hun marktaandeel behouden. Dingen als XML integratie/SOAP zijn leuk, maar *heel erg mager* voor een major update.

Je toespitsen op zaken als PHP aanroepbaar maken vanaf de commandline: hallo waar gaat dat nog om?

OO boeit nauwelijks; je gaat toch eigenlijk geen uitgebreide OO structuur opbouwen en objecten inlezen bij elke pagina aanroep. Het moest verbeterd worden, maar het is niet de Grote Update waar de webdev-wereld op zat te wachten.

Ze hadden er veel meer dingen in moeten stoppen zodat de development van webapps naar een nieuw niveau wordt getilt: dingen als interactie met het DOM model, abstractie van het pagina's opbouwen (een windowing toolkit iemand? waar blijven die libs in standaard PHP?) abstractie over de page generation/page request cyclus zijn zoveel meer waard als een gerepareerd OO model.

Als ze zo blijven steken als nu, gaan ze verliezen van bijvoorbeeld ASP en ASP.NET. Ze zitten zo dicht op hun eigen produkt dat ze de grote lijnen niet meer zien.


[...]

PHP weet in minor versions upgrade ook al backward compatibility te breken (is nu al meerdere malen gebeurd), dus ik vrees het ergste in de praktijk.

Als je het allemaal zo goed weet, dan ga jij toch lekker die extensies voor php schrijven.
't zijn verdorie een heleboel vrijwilligers die een mooi product op de markt zetten. Gratis! Kritiek kan geen kwaad, maar dit slaat werkelijk waar nergens op.
Je interactie met het DOM verhaal volg ik ook niet helemaal. Voor zover ik weet kan je in php5 gewoon domxml gebruiken en dus het DOM bewerken.

[Verwijderd]

Als je het allemaal zo goed weet, dan ga jij toch lekker die extensies voor php schrijven.

De eeuwige kutsmoes: het is Open Source dus moet je er zelf maar induiken en niemand is verantwoordelijk van de hack-op-hack structuur. Misschien moeten ze zelf eens een roadmap opstellen van hoe ze websoftware ontwikkeld willen zien over een paar jaar, ipv ad-hoc features erin te hacken.

't zijn verdorie een heleboel vrijwilligers die een mooi product op de markt zetten. Gratis! Kritiek kan geen kwaad, maar dit slaat werkelijk waar nergens op.

Een hoop vrijwilligers dus je zou willen dat PHP sterker wordt op de markt om hun werk niet langzaam in het niets te zien verdwijnen. Ze releasen na jaren eindelijk een PHP5, zit er nauwelijks iets boeiends in. Terwijl ze bijvoorbeeld hopeloos willen proberen de CLI markt te penetreren, worden ze links en rechts ingehaald op webdevelopment.

Juist omdat er zoveel mensen aan werken is het jammer dat het core team het niet weet te sturen naar een fundamenteel betere taal maar blijft steken in het toevoegen van toeters en bellen. Dat OO bijvoorbeeld had er vanaf het begin al goed in moeten zitten. Nu is het gewoon te laat: OO is een extratje in de taal, niet een van de basissen.

Natuurlijk is het allemaal gratis en alles; maar er werken enorm veel mensen mee. Als je dan als open source project geen visie meer hebt, stappen mensen over op commerciele oplossingen die dat gewoonweg wel hebben. Ook zie ik heus wel dat kennelijk mijn visie voor de toekomst van PHP niet die van hun is. Ik denk gewoonweg dat ze op deze manier gewoon marktaandeel gaan verliezen, en dat vind ik jammer: het laatste wat ik wil is dat Microsoft een monopolie weet te krijgen met ASP/ASP.NET. Misschien is het gewoon tijd voor een nieuwe taal, maar ook dat zou jammer zijn voor al die PHP vrijwilligers.

Je interactie met het DOM verhaal volg ik ook niet helemaal. Voor zover ik weet kan je in php5 gewoon domxml gebruiken en dus het DOM bewerken.

In een extensie ja; en nog erg sterk in de experimenteerfase.

Ook maken al die extensies de boel niet bepaald platform-onafhankelijk. Ook kan een gebruiker geen extensie toevoegen zonder hulp van de admin: leuk bij machines zoals ISPs. Fundamentele dingen moeten gewoon standaard in de taal zitten. Als ze dat DOM gedoe goed krijgen, is dat er eentje.

[.oisyn]

Verwijderd schreef op 29 september 2004 @ 15:57:
OO boeit nauwelijks; je gaat toch eigenlijk geen uitgebreide OO structuur opbouwen en objecten inlezen bij elke pagina aanroep. Het moest verbeterd worden, maar het is niet de Grote Update waar de webdev-wereld op zat te wachten.

Ze hadden er veel meer dingen in moeten stoppen zodat de development van webapps naar een nieuw niveau wordt getilt: dingen als interactie met het DOM model, abstractie van het pagina's opbouwen (een windowing toolkit iemand? waar blijven die libs in standaard PHP?) abstractie over de page generation/page request cyclus zijn zoveel meer waard als een gerepareerd OO model.

Daarnaast, de features die ze wel hebben geimplementeerd gaan helemaal nergens over. Namespaces zou er in komen maar is uiteindelijk toch weggelaten (uit de changelog van PHP 5.0.0 beta 2, 30 okt 2003: Removed the not so working namespaces support. Euh ja, wat een stel dorks). Exceptions zonder finally block, exception-safe code anyone? Het ultra-lelijke __construct en __destruct, alsmede de compleet nutteloze __get, __set en __call die alleen maar zorgen voor bad coding practices ipv goed ontworpen programma's. En dat laatste noemen ze dan "overloading", right . Daarnaast blijft de variable scope nog altijd bagger, en aan het ranzige type juggling moeten ze ook eens werken. Vertel mij eens, waarom is "blaat" hetzelfde als 0?

[ Voor 5% gewijzigd door .oisyn op 29-09-2004 19:00 ]

[.oisyn]

Verwijderd schreef op 29 september 2004 @ 16:31:
Als je het allemaal zo goed weet, dan ga jij toch lekker die extensies voor php schrijven. 't zijn verdorie een heleboel vrijwilligers die een mooi product op de markt zetten.

Jij zeurt zeker ook niet over politiek omdat je er zelf niet in zit?

[ Voor 16% gewijzigd door .oisyn op 29-09-2004 18:59 ]

[-Lars-]

.oisyn schreef op 29 september 2004 @ 18:59:
[...]
Jij zeurt zeker ook niet over politiek omdat je er zelf niet in zit?

Aan de ontwikkelingen in de politiek kun je zelf elke 4 jaar een sturing geven. Verder kun je je kritiek op de politiek via allerlei wegen laten doorluiden in Den Haag.
(En voordat iedereen gaat zeuren dat de politiek toch niet luistert naar jou alleen: je bent niet alleen en de politiek moet ook rekening houden met anderen.)

NoFI, maar als je echt wilt bijdragen aan het verbeteren dan moet je feedback geven aan de ontiwkkelaars en niet gaan mokken op GoT (= Nederlandstalig, dus als je hier klaagt zullen ontwikkelaars er waarschijnlijk nooit achterkomen).

Verder zullen julie vast wel gelijk hebben dat PHP5 niet alle voor de hand liggende nieuwe features heeft geimplementeerd , ben nog maar net met PHP begonnen en kan daar niet over oordelen.

[.oisyn]

-Larz- schreef op 29 september 2004 @ 19:24:
Aan de ontwikkelingen in de politiek kun je zelf elke 4 jaar een sturing geven. Verder kun je je kritiek op de politiek via allerlei wegen laten doorluiden in Den Haag.
(En voordat iedereen gaat zeuren dat de politiek toch niet luistert naar jou alleen: je bent niet alleen en de politiek moet ook rekening houden met anderen.)

Net als dat je je stem kunt laten horen aan de PHP devvers. Of ze er wat mee doen is een tweede, net als in de politiek. Fijn dat je even de argumentatie van mijn analogie geeft

NoFI, maar als je echt wilt bijdragen aan het verbeteren dan moet je feedback geven aan de ontiwkkelaars en niet gaan mokken op GoT (= Nederlandstalig, dus als je hier klaagt zullen ontwikkelaars er waarschijnlijk nooit achterkomen).

Ten eerste weet jij helemaal niet wat er verder door ons aan feedback wordt gegeven aan het PHP team, ten tweede betekent dat nog niet dat je hier vervolgens niet mag ranten op PHP. Het "je mag niet zeuren want die mensen werken er in hun vrije tijd aan en anders ga je maar meehelpen" slaat gewoon nergens op. Ik ben het niet eens met de manier waarop de taal PHP in elkaar zit, en aangezien we nog altijd de vrijheid van meningsuiting hebben hier in nederland mag ik (of wie dan ook) dat ook uiten waar ik dat gepast vind. Op dit moment is dat GoT.

[Olaf van der Spek]

.oisyn schreef op 29 september 2004 @ 18:58:
Daarnaast blijft de variable scope nog altijd bagger, en aan het ranzige type juggling moeten ze ook eens werken. Vertel mij eens, waarom is "blaat" hetzelfde als 0?

Ik dacht er laatst nog aan. Ik ben C++ gewend, maar is het type systeem van PHP nu echt eenvoudiger/makkelijker dan C++?
De meeste code die ik zie staat nu vol met type-checks, terwijl die normaal eenvoudig en simpel door de compiler worden afgehandeld.

[.oisyn]

Het is makkelijker in de zin dat getallen in integers automatisch geconverteert worden, en zo kun je dus user input (wat altijd een string is) bewerken als getallen. Het is echter krom dat een string dat geen getal is probleemloos naar een (int)0 wordt omgezet, waardoor de volgende code "FOUT!" output:

PHP:

if ("blaat" == 0)
    echo "FOUT!";

Imho zou je bij zo'n statement niet alleen een domme automatische conversie moeten doen, maar eerst kijken of "blaat" wel daadwerkelijk naar een int te converteren is. Als dat niet zo is dan zou ie gewoon false moeten geven.

[elevator]

Dat is vergelijkbaar met dat:

PHP:

if( NULL == 0) { echo "Fout!"; }

ook Fout! oplevert, maar volgens mij kan je beide oplossen door:

PHP:

if( NULL === 0) { echo "Fout"; }
if( "blaat" === 0) { echo "Fout"; }

te gebruiken?

[.oisyn]

Duh, maar dat werkt dan niet meer als "blaat" de string "0" was geweest, terwijl je wil dat dat wel true oplevert. Met constante waarden is het een beetje loos, maar stel dat je een variabele $blaat had gehad, en een andere variabele $melp, die je met elkaar wilt vergelijken. Als $blaat een niet-numerieke string is, en $melp een int of float gelijk aan 0, dan geeft dat dus mooi true, terwijl ze geenszins gelijk aan elkaar zijn.

[ Voor 3% gewijzigd door .oisyn op 29-09-2004 21:44 ]

[elevator]

Het zou alleen een 'true' geven als $melp dan 0 is, in andere gevallen niet lijkt me?

Ik vind het overigens ook geen mooi systeem maar het is toch enigszins verbonden aan het loosetyped zijn van php wat ook weer het gemakkelijke eraan is

[.oisyn]

Jaha, het is ook handig dat je een string met een int kunt vergelijken, maar het is gewoon dom dat een string dat geen int is vergeleken met een int die 0 is true oplevert. Of vind je dat normaal gedrag?

[elevator]

Een conversie van een string naar een int levert altijd 0 op - als je er van uit gaat dat PHP 'onderhuids' die conversie van int->string doet levert het een 0 op en is het dus aanvaardbaar.

[.oisyn]

En die hele filosofie klopt dus niet! Een niet-numerieke string converteren naar int is niet 0, het is een niet-gedefinieerde waarde. Waarom zou het 0 moeten zijn? En waarom dan geen -1 (ik zeg maar wat). De meeste talen gooien een exception of zetten een error bit als je een string naar int probeert te converteren terwijl dat niet kan. "0" of "000" of iets in die trant kan naar 0 omgezet worden, "blaat" niet. En nee, ik vind het dus niet aanvaardbaar, je vergelijkt een string met een int, dan moet er gekeken worden of die string wel geconverteerd kan worden naar een int ipv domweg maar 0 te gebruiken als het niet converteerbaar is.

[elevator]

Ik ben het met je eens dat het geven van een exceptie mooier zou zijn hoor, echter bij een taal die geen excepties kent is dat niet mogelijk

Bij impliciete conversie kan je dus ook niet een error-code teruggeven, en als je dan naar de standaard functies van bv. Delphi of C kijkt (Val() of atoi() ) dan zie je dat die ook een 0 terug geven bij een mislukt conversie - het is dan ook wel degelijk standaard gedrag en dus ook anvaardbaar.

[.oisyn]

Nee, nu heb je het over een expliciete cast. Als ik (int)$blaat doe vind ik het niet erg dat ie 0 terug geeft, ik cast expliciet dus ik kan ook expliciet controleren met bijvoorbeeld is_numeric. De == operator werkt echter op een string en op een int. Het is de operator die cast, en het kan dus ook de operator zijn die de controle doet.

in pseudocode:

C++:

bool operator == (string s, int i)
{
    if (!is_numeric (s))
        return false;
    return (int)s == i;
}

Dat is prima te implementeren, en dát is wat ik aanvaardbaar vindt. Javascript kan het toch ook, om maar een voorbeeld te noemen?

[elevator]

Daar zit wat in inderdaad

[ Voor 6% gewijzigd door elevator op 29-09-2004 22:24 ]

[Olaf van der Spek]

.oisyn schreef op 29 september 2004 @ 21:31:
Het is makkelijker in de zin dat getallen in integers automatisch geconverteert worden, en zo kun je dus user input (wat altijd een string is) bewerken als getallen.

Maar wordt voor die eenvoud niet erg veel opgeofferd?
En de input moet toch gechecked worden, hoe moeilijk is het om het daar gelijk te converteren?