PHP 7.0 is uitgebracht met nieuwe functies

PHP 7 is uitgekomen. Daarmee is het de eerste stabiele versie sinds PHP 5.6 iets meer dan een jaar geleden uitkwam. PHP 7 belooft betere prestaties door gebruik te maken van Zend Engine 3.0. De responstijden zijn lager geworden en er kunnen meer gebruikers met minder servers toe.

De nieuwe versie volgt op een serie van acht release candidates en bevat verschillende nieuwe functies. Onder andere is de 64bit-ondersteuning nu consistent tussen verschillende platforms, iets wat vooral de portabiliteit van de code beter moet maken. Ook is het geheugengebruik 'significant' teruggebracht, wat al lang een wens was van PHP-ontwikkelaar Dmitry Stogov. De snelheid zou ten opzichte van 5.6 verdubbeld zijn en er is een abstract syntax tree toegevoegd. Verder zijn er nieuwe operators toegevoegd, zoals de nieuwe drieweg logische operator, de combined-comparison of spaceship-operator. Een tweede nieuwe operator is de null coalescing operator "??".

Ook is er veel oude code verwijderd, zoals functies die sinds de 5.x-versies gedeprecieerd waren. Ook is een lange lijst aan oude en niet meer ondersteunde sapi's, of Server Application Programming Interfaces, verwijderd, zoals manieren om te verbinden met AOL, Apache 1.x en Microsoft IIS.

PHP 7 is gebaseerd op phpng of php Next Gen. Volgens de Zend-website verdubbelt de phpng-engine de snelheid in veel gevallen. Zend geeft als voorbeeld dat ten tijde van de introductie van phpng een Wordpress-pagina gemiddeld 9,4 miljard cpu-instructies nodig had om uitgevoerd te worden en dat dit nu is teruggebracht tot 2,6 miljard.

Dat PHP 6.0 als versienummer is overgeslagen, komt doordat er een tekort was aan ontwikkelaars die zich wilden bezighouden met bepaalde unicode-functionaliteiten met betrekking tot strings. In PHP 7.0 zitten wel enkele unicode-wijzigingen ten opzichte van de 5.x-versies zoals de toevoeging van een unicode-escape-syntax \u. Het bevat niet de grote wijzigingen rond unicode die voor 6.0 bedoeld waren.

Nog niet alle modules zijn geüpgraded naar de nieuwe versie van de scripttaal. Om die reden zal het ook nog even duren voordat bijvoorbeeld Tweakers over kan.

Reacties (109)

[Loller1]

6.0 is overgeslagen omdat er al boeken en documentatie was over PHP6 en omdat dit verwarrend zou zijn, niet om de reden in dit artikel.

Anyway, fijn dat het er nu is/

[VincentdeVreede]

Voor de mensen die iets meer informatie willen.
PHP6, The missing version number

[xleeuwx]

HIer staat niet concreet in welke bronnen hij heeft gebruikt en dus kan je niet voor alle zekerheid zeggen dat dit de reden is.

[RoelRoel]

Ik denk al: die rede in het artikel slaat echt nergens op: Er waren niet genoeg ontwikkelaars voor versie 6 dus zijn we maar aan versie 7 begonnen

[mattiasgeniar]

Niet echt: PHP 6 bleef aanslepen, unicode kwam er niet correct door en bleef bugs bevatten. Die feature is gewoon nooit af geraakt. Mogelijk door een tekort aan developers, mogelijk door een hele hoop externe factoren die de development hebben beïnvloedt.

Bottom line: PHP 6 is "gefaald" en daardoor skipt men de versie.

[roy-t]

Volgens mij is er een plan gemaakt voor PHP6 over hoe dingen zou moeten werken. Dat had grotendeels met (unicode) string handling te maken. De boeken die geschreven zijn legde de standaard uit (ook al was er nog geen implementatie). Uiteindelijk is versie 6 nooit gemaakt (string handling is EN heel ingewikkeld EN heel erg vervelend EN niet erg prestigieus om te maken).

Dus de uitleg klopt volgens mij wel redelijk.

[Loller1]

De uitleg in het artikel slaat nergens op, de gegeven uitleg is waarom ze opnieuw zijn begonnen, niet waarom ze 6.0 hebben overgeslagen en door zijn gegaan naar 7.0, maar het artikel zegt wel dat de gegeven reden daarom is. Het feit dat er niet genoeg ontwikkelaars waren heeft niks te maken met het uiteindelijke versienummer.

[3raser]

Gaat Tweakers ook een review maken van de verbeterde prestaties? Hij lijkt me interessant om te zien wat de upgrade naar PHP 7 doet met de prestaties van de webservers op een website zoals deze.

[batjes]

In het andere topic had ik deze gelinkt.

Resource load is bij beide tests op het systeem gelijk. (Even lokaal getest via simpele benchmark script)

http://imgur.com/yLjqHZT
Benchmark staat niet gelijk aan real world scenario's en deze is gemaakt op 5.6 en niet 7.0. Maar het geeft een indicatie

Windows + IIS overigens, Apache e.d. kan anders zijn.

*overigens aan het kijken dit even te testen op Debian + Apache.

[Reactie gewijzigd door batjes op 25 juli 2024 19:33]

[Toettoetdaan]

Bekijk deze sheet anders even: https://docs.google.com/s...it#gid=1534868447&vpid=A1

Dit is hoe Zend zelf heeft getest: https://wiki.php.net/phpng#performance_evaluation
(Daar kun je ook zien dat dat 2,6 miljard nummer van Wordpress voor 100 requests is)

En deze mabdelbrot benchmark is ook interessant, maar het is geen real world: https://gist.github.com/d...d13d3240aee8f1#file-b-txt
Als deze resultaten kloppen kan het wel zo zijn dat PHP wat wint aan populariteit voor de kleine bash scriptjes.

[batjes]

Dat zijn mooie resultaten. Ik had ook geen zin er zelf 1 te schrijven (Ik heb ergens nog wel een oud zwaar script die een hele range aan ifelse, switch, loops, fors e.d heeft liggen maar ik mis de database ervan) en had het van het internet geplukt.

Goed te zien dat het dus ook op beide platformen zo verbeterd is.

Net even explode en count_chars toegevoegd aan de string manipulatie. 17.163 seconden voor test_stringmanipulation op PHP 7.0. En op PHP 5.6 krijgt hij een timeout op deze functie (default configs, 300seconden)

[Reactie gewijzigd door batjes op 25 juli 2024 19:33]

[desmond]

Je ¨Total time" klopt niet in dit plaatje; het verschil is veel groter.

[batjes]

Total time klopt wel, had het niet geverifieerd omdat het leek te kloppen, net gecalculatord en total time is daar hetzelfde bij beide versies.

test_stringmanipulation geeft een vertekend beeld, er explode en count_chars bij toegevoegd en het verschil is al 17.163sec voor php7 tegenover 5min+ timeout van PHP 5.6

[divvid]

Ik zou dan graag een vergelijking zien tussen de performances van verschillende populaire talen in soortgelijke applicaties, maar of dat nou zo makkelijk is ...

[Superstoned]

Er zijn wel een paar benchmarks maar meestal 'met agenda' zogezegd... Het is ook lastig omdat er super veel functies zijn in elke taal, sommige snel, andere langzaam. Dan heb je nog combinaties en discussie over wat goed of niet goed geschreven is... Bijv. een goed geschreven ruby app zal best sneller zijn dan een slecht geschreven C app.

[d22wth]

Lijkt me leuk!

[Darsstar]

Voor iedereen die het interessant vindt, de vote tussen PHP 6 en PHP 7: https://wiki.php.net/rfc/php6

[5pë©ïàál_Tèkén]

Grote vraag is: is mySQL nou eindelijk deprecated en begraven zodat alleen mySQLi werkt?

[dev10]

Jep: http://php.net/mysql_query

[3raser]

Ja. Zie de verwijderde extensies.

[xleeuwx]

Inderdaad en dat werd eens tijd.

[Anoniem: 26306]

Ik hoop dat je PDO gebruikt en geen MySQLi.

[434365]

Yeuy eindelijk support voor ruimteschepen
(zonder gekkigheid, die dingen zijn handig, top dat ze nu ondersteund worden)

Die ?? ziet er ook leuk uit, is zo te zien een soort single line if isset statement, tof

[Reactie gewijzigd door 434365 op 25 juli 2024 19:33]

[Zayl]

Correct, waar je voorheen isset($a) ? $a : null moest doen, wordt nu $a ?? null; ondersteund. Vergelijkbaar met hoe $a ? $a : null; gelijk is aan $a ?: null;

[434365]

Kijk, daar hou ik van, nog minder typen

[Zayl]

Let wel op de volgorde, $a ?? $b ?? $c; etc. Ik weet niet precies wat de juiste execution order is ivm de verandering van de abstract syntax tree. Voorheen zou dat $c, $b, $a zijn en dat is nu volgens mij $a, $b, $c.

[434365]

Ja als ik naar de documentatie kijk denk ik ook dat het dan in de volgorde $a $b $c word gedaan

Hier trouwens de documentatie (deze link mist in het artikel, ook even feedback over gegeven)

[SliceOfLife]

PHP gaat er goed op vooruit sinds de laatste releases, hulde!

[RoestVrijStaal]

Helaas zijn er nog steeds veel vieze dingen aanwezig: http://www.phpsadness.com/

En bij een aantal van die gevallen hebben de oplossingen zelfs een WONTFIX van het dev team gekregen ook

[Anoniem: 457607]

Dit valt onder de categorie "PHP sucks, but it doesn't matter".

Jazeker is het taaltechnisch geen schoolvoorbeeld, maar dat is voor een deel puristisch geneuzel. Een beetje developer is binnen een paar maanden bekend met de PHP rariteiten en kan er daarna extreem produktief mee zijn, en dat is wat echt telt.

[Aaargh!]

Jazeker is het taaltechnisch geen schoolvoorbeeld, maar dat is voor een deel puristisch geneuzel.

Een groot deel van de viezigheden in PHP verhoogt de kans op bugs aanzienlijk. Dit geld zeker voor dingen als automatische type conversies i.c.m. vergelijkingen waardoor in randgevallen je een totaal verkeerd code-pad in gaat. Dit is zeker geen puristisch geneuzel maar een groot risico voor veel applicaties, zeker als je met privacy-gevoelige data werkt. Verder mist er gewoon te veel in PHP, geen container-managed security, geen CDI, geen audit support, etc. Ja er zijn overal libraries en frameworks voor maar er zijn geen standaarden en het is maar de vraag of het allemaal samenwerkt.

Ik zou het iig nooit gebruiken voor kritieke toepassingen. De kans op fouten is gewoon te groot.

[BCage]

[...]

Een groot deel van de viezigheden in PHP verhoogt de kans op bugs aanzienlijk. Dit geld zeker voor dingen als automatische type conversies

Ja, dat hoor ik iedereen altijd zeggen. Ik ben na 10 jaar professioneel PHP programmeren wel eens benieuwd wat nou die vreselijke bugs zijn. Ik ben ze in ieder geval nooit tegen gekomen. En voor veel van je andere bezwaren hebben we tegenwoordig Symfony (of Laravel), die inmiddels wel industriestandaarden genoemd mogen worden. PHP is volwassen, zeker in combinatie met genoemde frameworks. In handen van goede programmeurs / professionals is er niks aan de hand.

Ja, beginners zullen misschien tegen die bugs aanlopen, maar dat is dan jammer. Het weegt niet op tegen het gemak wat ze (en ik) er wel van hebben. Van origine is het nou eenmaal een laagdrempelige taal, wat ook zijn populariteit verklaart.

[Reactie gewijzigd door BCage op 25 juli 2024 19:33]

[Xander2]

Er zitten bugs in die je als beginnende PHPer zeker niet gauw tegenkomt,
b.v. de niet stabiele sorteer algorithmes.
Daarnaast vind ik Symfony of de meeste andere frameworks een te hoge
drempel hebben om als beginnend PHPer aan te merken.
Meestal zal dit in de trant van w3schools zijn en dan spelen XSS en type conversies wel degelijk een rol.
En 0, null, false, '' type testing vs. boolean testing blijft een dubbelcheck
moment.

[Anoniem: 457607]

Type conversies is een klassiek argument wat beide kanten op kan vallen. Loosely typed is in veel gevallen juist een voordeel en een karakteristiek van een scripting taal tov de meer klassieke languages.

Maar goed, wederom is dit voornamelijk theoretisch gebral, want als je strongely typed code wil, dan is dat hooguit een paar slechte gewoontes afleren. En als je developers het dan nog steeds verkeerd doen, dan run je gewoon Sonar als onderdeel van je build of check-in proces, en dan heb je het gewoon opgelost.

[shades]

En wat zijn volgens jou dan de betere alternatieven?
c#.net? python? ror? of weet ik veel wat er tegenwoordig allemaal is?

[Anoniem: 457607]

Wat bedoel je? Ik nam het juist op voor PHP.

[shades]

Oke - ik kom zelf uit de c# hoek maar heb dat een jaar of 4 moeten opgeven. Ben nu een maandje met php aan het stoeien en wilde gewoon weten wat de andere altenatieven zijn - mijn reactie was niet als negatief commentaar bedoelt, meer als vraag (maar nu ik het teruglees staat het wel een beetje bot)

[Anoniem: 457607]

Ik pakte het niet zo op hoor, vroeg me af waar de vraag vandaan komt.

Ikzelf heb gewerkt met PHP, C#, JS, Java, en zelfs nog wat oudere talen. Ik heb geen enkele voorkeur voor welke taal dan ook, omdat de taal zelf zowat het minst belangrijkste is in software ontwikkeling.

[roy-t]

Er is een hoop puristisch geneuzel. Ik vind het zelf wel fijn als bijvoorbeeld alle functies de zelfde manier van naamgeving hebben, of als verschillende functies op strings argumenten op dezelfde volgorde listen. Maar dat zijn inderdaad dingen die je snel kan leren.

Helaas heeft PHP (en ook javascript bijvoorbeeld) een hoop quircks die je niet zou verwachten waardoor je hele onverwachte bugs kunt krijgen. Het duurt lang voordat je de meeste van die door hebt (maar aangezien de meeste websites op PHP draaien is dat ook overkomelijk)

[Vale vista]

Idd, om maar naar niet te beginnen over css. Wat n rotzooi is dat, allemaal onverwachte dingen en standaarden. Vreselijk. Om nog maar te zwijgen over het zoeken naar waar het probleem zit.

[RoestVrijStaal]

Laat ik het zo zeggen, bij "communicatie-talen" tussen mensen, bij spraak, schrift, gebarentaal en braille kan ik nog wel snappen dat veranderingen lastig zo niet praktisch onmogelijk zijn door de voeren, vanwege tradities, cultuur en historische achtergronden.

Een computertaal (m.u.v. Assembly en varianten op dat niveau) kan en hoort ook te veranderen, want het is enkel een tussenlaag tussen talen die mensen snappen en "talen" die computers snappen.

Ik zie daarom ook niet in waarom wij developers het voor onszelf moeilijker moeten maken om quirks erin houden. Hoe minder je met quirks rekening moet houden, hoe meer je kunt focussen op je doel en wat je echt wil i.p.v. om vuile heilige huisjes heen te werken.

Edit: Oeps

[Reactie gewijzigd door RoestVrijStaal op 25 juli 2024 19:33]

[Zayl]

Ik zag het probleem van private methods niet kunnen mocken. Dat is naar mijn mening juist goed, moet je de structuur maar goed opzetten. Je kan altijd een object injecteren en de method daar in stoppen. Blijkbaar is de functionaliteit van je private dusdanig belangerijk (of met te veel side effects), dat het daar niet in thuis hoort.

http://www.phpsadness.com/sad/33

Wat leuk leesvoer:
http://shaneauckland.co.u...eps-your-privates-hidden/

[RoestVrijStaal]

Ik denk eerder dat het voorbeeld van die sadness slecht is, zodat wat er verbeterd moet worden onbelicht blijft. Namelijk dat je in PHP geen private method van een superclass kunt overriden in een subclass.

[ACM]

Dat klinkt als iets heel raars. En dat kan vziw in bijvoorbeeld Java ook niet. Er hoort gewoon geen kennis van het feit dat er een bepaalde private methode is buiten de class te zijn.

Als die methode bekend moet zijn bij de subclass, dan is het blijkbaar geen private methode. Dan is ie blijkbaar protected. Ik snap ook niet waarom de protected-markering geen geldig alternatief zou zijn.

Ik ben benieuwd naar welke use cases er zouden zijn? En testing is niet het beste voorbeeld; dan had je blijkbaar die functionaliteit al op een andere manier los moeten weken.
Jij herhaalt in je reactie eigenlijk gewoon het aangehaalde sadness-punt zonder toe te lichten waarom het een probleem is (en dat staat ook niet op die sadness-pagina).

Wat wel jammer is, is dat je ook erg weinig met protected kan in php en je al gauw dingen public moet maken als je het op de juiste wijze wil testen.
Bij bijvoorbeeld Java kan je dingen protected maken en binnen dezelfde package gewoon testen zonder subclasses te gebruiken. En daarnaast kan je nog dingen doen met private en package-local nested classes.

[RoestVrijStaal]

Zo raar is het niet. In C++ kan je wel private methods overriden. C++ FAQ heeft er een mooie uitleg en voorbeeld over:
https://isocpp.org/wiki/f...eritance#private-virtuals

Wellicht zullen er andere oplossingen zijn. Hangt van de use case af en hoeveel werk de andere oplossingen kosten.

[HellStorm666]

Ik gebruik php-fpm.... is dan alsnog PHP gewoon te updaten naar php7?
(gebruik concrete5 op nginx met http2)

[GieltjE]

Ja, onderliggend is het gewoon php met een apparte fast-cgi handler waarbij php dus los staat van je service.

[biglia]

Dat mis ik wel een beetje bij ASP.NET . Daar zijn ook al zoveel nieuwe versies uitgekomen, maar een versie waarbij de performance een boost krijgt, ben ik nog niet tegengekomen.

[rvdhoek]

ASP.NET 5 is nu een Release Candidate. Naast dat deze versie op linux werkt is het ook niet meer afhankelijk van IIS webserver. Daarmee is de performance ook enorm verbeterd. In de berichten lees ik dat het sneller zal zijn dan node.js. Maar het is nog maar een RC versie.

[afraca]

Voor m'n werk gebruiken we Laravel
[PHP] Het grote Laravel topic
http://laravel.com/

Redelijk eenvoudig in te stappen framework Daar zijn ze al heel vroeg begonnen met porten naar 7.0 , dus dat zit al helemaal goed, mocht iemand zich dat afvragen. Net even kort getest met ons inhouse CMS, en dat lijkt ook prima te gaan vooralsnog.

[lukjah]

Alle unit tests draaien op al 7 ja. Mijn Laravel website draait zonder problemen op HHVM en lokaal op php 7 (hhvm draait niet op windows).

[Patrock]

Moodle en wordpress draaien op mijn testserver behoorlijk wat sneller na installatie van php7. Moodle is er nog niet helemaal klaar voor, je mag het niet eens installeren via php7! maar na een paar kleine errors die worden gelogd voelt alles lekker soepel en solide aan!

xmlrpc is de enigste php extensie die ik zo niet mee zag komen

[Reactie gewijzigd door Patrock op 25 juli 2024 19:33]

[Jan-E]

xmlrpc is wel degelijk geport naar PHP7. Ik compileer PHP zelf onder Windows en dan krijg je zo'n PHPinfo():
https://phpdev.toolsforre....0-nts-Win32-VC14-x64.htm
Builds beschikbaar via
http://www.apachelounge.com/viewtopic.php?t=6359

Nog niet alle modules zijn geüpgraded naar de nieuwe versie van de scripttaal. Om die reden zal het ook nog even duren voordat bijvoorbeeld Tweakers over kan.

@tweakers:welke extensie missen jullie? Sommige van de extensies in mijn builds zijn nog niet officieel uitgebracht, maar werken wel. Sommige zijn overigens ook terecht nog niet uitgebracht, omdat er nog issues op te lossen zijn. redis en igbinary zijn voorbeelden van ports met issues.