Onderwerp: Scripters: PHP 4 of 5?

Voor de scripters onder ons welke php gebruik jullie versie 4 of 5?
Ik gebruik namelijk nog 4 omdat mijn webhost nog geen 5 heeft en omdat ik te weinig tijd heb me er in te gaan verdiepen!
Maar ik ben dus benieuwd met welke versie jullie scripten!

Op dit moment 4 omdat ik het goed ken en qua code alle optimalisaties goed weet. Ik ben wel druk bezig met PHP 5 en dus ga ik in de toekomst dit vaker toepassen.

Op het moment ook nog 'object-georrienteerd' php4. Wij hebben PHP5 al wel draaien voor enkele klanten, maar ik ben er zelf nog niet veel mee bezig geweest. Staat nog wel op de To-Do list

Oorspronkelijk geplaatst door CharlieRoot

Op dit moment 4 omdat ik het goed ken en qua code alle optimalisaties goed weet. Ik ben wel druk bezig met PHP 5 en dus ga ik in de toekomst dit vaker toepassen.

Slap smoesje

Het enige grote verschil tussen versie 4 en 5 is het OOP programmeren. Als jij in PHP4 niet werkt met klassen, zal je in versie 5 even ge-optimaliseerd kunnen werken. De verschillen komen pas in OOP-land, maar zelfs dan zijn ze te overzien.

Ik werk alleen nog maar met versie 5 en dan ook nog volledig OOP.

Kleine dingetjes gewoon in PHP4, maar al het grote werk in PHP5, simpelweg omdat OO er toch weer wat beter gesupport is dan in PHP4 (alhoewel het nog steeds behelpen is hoor met PHP).

PHP4 nog steeds...

Wat is er dan aan de manier van coden in PHP5 (OOP) veranderd?
Maak nu alles nog in OOP4.. zou niet zo fijn zijn als dat alles straks overnieuw moet!

In PHP5 zijn er vooral veel dingen toegevoegd. De grootste wijziging die niet backwards compatible is, is dat objecten vanaf nu standaard by reference worden doorgegeven (itt by value zoals in PHP4), wat een hoop gezeik scheelt bij het per ongeluk vergeten van een &. Verder zijn exceptions toegevoegd, en is er eigenlijk heel veel op OOP gebied toegevoegd (data hiding, overloading, type hinting etc., zie http://nl2.php.net/manual/en/language.oop5.php ).
Je hoeft niet snel bang te zijn dat je PHP4 code niet meer werkt, echt had OO in PHP4 gewoon totaal geen nut, en is dat nu iets beter geworden.

de heren van php bij OOP goed gekeken naar java ?

Mwa, het haalt het bij lange na nog niet bij Java (of nog betere OOP talen als bv. Ruby), maar ach, het blijft natuurlijk een beetje een prutstaal.

PHP4, zie nog geen nut om op PHP5 over te gaan. Zo ingewikkelde dingen doe ik niet.

PHP4, omdat alle (op een na) servers hier nog op draaien. Applicaties worden echter wel getest op conpatibliteit in PHP5. (Tevens op Windows).

Moet me nog verdiepen in diverse nieuwe features. Thans ligt de proiriteit echter op enkele andere trainingen.

Oorspronkelijk geplaatst door MikeN

Mwa, het haalt het bij lange na nog niet bij Java (of nog betere OOP talen als bv. Ruby), maar ach, het blijft natuurlijk een beetje een prutstaal.

Prutstaal, *kuch*

Het is een hele goede taal, er zijn alleen soms prutsers die er mee werken!

Oorspronkelijk geplaatst door Wido

Prutstaal, *kuch*

Het is een hele goede taal, er zijn alleen soms prutsers die er mee werken!

Feit is dat er door de PHP developers tot aan PHP4 kneiterhard is aangeknoeid wanneer het aankwam op naming van de eigen functies. Functies hebben inconsistente namen gekregen (zie alleen al http://nl2.php.net/strings , sommige met str, sommige met str_, sommige zonder prefix) en de taal is een steeds groter zooitje geworden, iets wat met de intro van PHP4 al verbeterd had moeten worden (jaren terug praten we dan dus over). Inmiddels zijn we bij PHP5, proberen ze nog steeds de rotzooi op te ruimen, maar zitten ze nu gigantisch met de backwards compatibiliteit die ze erin moeten houden waardoor de API nog steeds een zooitje is.

PHP is maar een weinig opzichten een goede taal, wat betreft opbouw of netheid is PHP dat in ieder geval zeker niet. Dat er dan ook nog eens bergen randdebielen zijn die er totaal niet mee overweg kunnen maakt het alleen maar erger.

Ik ben het helaas met MikeN eens. PHP wordt ontwikkeld zoals Linux in de vroegere jaren: alles wordt er maar ingegooid zonder kwaliteitsbewaking of een integraal ontwerp. Maar bij PHP zit je met de gebakken peren en je komt er niet meer af vanwege backward compatibility. Die API is zo verschrikkelijk, dat kom je niet vaak meer tegen. Nog steeds ben ik constant functieargumenten aan het opzoeken, omdat het zo inconsistent is als de pest. Heel vervelend. Sommige fouten, zoals register_globals, worden wel gecorrigeerd na verloop van tijd, maar ja: ik heb geprobeerd om honderden virtualhosting klanten uit te leggen waarom hun FoUtLoZe ScrIppieJ bij ons niet draait, dat werkt niet, dus feitelijk moet je het wel aanhouden. Andere problemen worden gelukkig helemaal niet gefixt. Header injection attacks via de mail functie, ach ja, wie heeft er nou eigenlijk last van?

Het is ook een van de weinige projecten waar ze in minor versies allerlei basale zaken wijzigen zoals in GD en safe mode; erg prettig als je virtual hosting runt voor mensen en ze dan moet uitleggen waarom hun standaardscripts niet meer werken nadat je een PHP update hebt gedaan... (MySQL is hier ook goed in, wat dat betreft zijn ze een perfecte combinatie :\)

Ik vind wel dat je het de randdebielen enigzins moet vergeven: PHP zelf nodigt uit tot onveilig coden. Maar ja, wat moet je anders. Ik had liever gezien dat een betere taal het had gewonnen, maar voor de meeste web toepassingen is PHP toch nog wel een goede keus.

tja wij hebben op het werk 50000+ regels eigen library code liggen, waarmee een en ander in vroeger jaren wat draaglijker werd, dat schept toch een band. maar PHP is geen Python inderdaad.