Software-update: PHP 8.4.1

Versie 8.4.1 van PHP is uitgebracht, de eerste stabiele uitgave in de 8.4-serie. Tegelijk zijn er ook updates voor versie 8.1, 8.2 en 8.3 verschenen. PHP is een recursief acroniem en staat voor PHP: Hypertext Preprocessor. Het wordt voornamelijk gebruikt om op webservers dynamische webpagina's te creëren, vaak in combinatie met databaseprogramma's. De complete lijst met veranderingen is op deze pagina in te zien, dit zijn in het kort de belangrijkste:

PHP 8.4.1 Released!

The PHP development team announces the immediate availability of PHP 8.4.1. This release marks the latest minor release of the PHP language. PHP 8.4 comes with numerous improvements and new features such as:

• Property Hooks
• Asymmetric Property Visibility
• Lazy Objects
• PDO driver-specific subclasses
• BCMath object type
• And much much more...

For source downloads of PHP 8.4.1 please visit our downloads page, Windows source and binaries can be found on windows.php.net/download/. The list of changes is recorded in the ChangeLog. The migration guide is available in the PHP Manual. Please consult it for the detailed list of new features and backward incompatible changes.

Versienummer	8.4.1
Releasestatus	Final
Besturingssystemen	Scripttaal, Linux, BSD, macOS, Solaris, Windows 8, Windows 10, Windows Server 2016, Windows Server 2019, Windows 11, Windows Server 2022, Windows Server 2025
Website	PHP
Download	https://www.php.net/downloads.php
Licentietype	Voorwaarden (GNU/BSD/etc.)

Reacties (43)

[CapnCrinkle]

Asymmetric Property Visibility vind ik als iemand die zelf frameworks maakt dus echt een flinke plus. Het kunnen getten van een variable buiten de class, zonder hem te kunnen setten scheelt gewoon enorm veel nodeloze functies om het af te vangen.

PHP had al een enorme sprong gemaakt met strict params. Vervolgens werd ik nóg gelukkig van named params (dit nam een hele hoop opschoning van code met zich mee) en hoewel ik Lazy Objects als nuttig zie, heb ik dat al lang zelf op moeten lossen wegens tekortkomingen.

De Asymmetrric Property Visibility heb ik natuurlijk ook wel opgelost, maar vond ik altijd wat slordig omdat het niet nodig zou moeten zijn. Bij deze is het vanaf nu dus mogelijk om het direct te doen, wat echt een coole vooruitgang is! PHP wordt steeds fijner in het gebruik!

[ArmEagle]

Ik vind het wel veel code rondom de constructor/properties. Maar dat is misschien gewoon wat wennen.

[CapnCrinkle]

Heb je het daarmee niet over de property hooks?
In dat geval ben ik het volledig met je eens. Ik vind de property hooks niet interessant omdat ik ten eerste niet vind dat je een 'automatisch' effect moet hebben op de values die je set (gewoon een beetje gekkig als je een variable set op "myString" en wanneer je het weer gebruikt het opeens "Mystring" is, gebruik dan gewoon een functie of een class als variable. Dat voelt niet correct) en ik wil ook al die "spam" niet zien in mijn variable declarations.

De Asymmetric Property Visibility vind ik echter juist niet "veel code".

De korte regel

public private(set) string $name = "Henk";

Vervangt complete structurele lappen aan code en functies (en vooral; magic getters en setters), wat in mijn ogen ook nog wat idiotproofing doet omdat je juist met die magic getters en setters eigenlijk het hele doel van protected/private variables voorbij gaat.

Nu kun je de "standaard" structuur aanhouden van b.v. $foo->bar i.p.v. $foo->get('bar') of $foo->get->bar() te moeten doen. Als je vervolgens probeert te zeggen $foo->bar = "baz", krijg je een error.

Dit houdt je code consistenter. Een variable getten en setten zou gewoon $foo->bar moeten zijn. Persoonlijk altijd een hekel gehad aan het gebruiken van een functie of class ( $foo->get('bar') ) om een variable te getten. Het doet voor mij gewoon iets met de leesbaarheid en duidelijkheid. Maar dat kan ook aan mij liggen hoor. Ik heb nogal eens verschillende meningen tegenover andere developers. Ben wat meer "creatief" van aard, zeg maar

[Memori]

Het doet voor mij gewoon iets met de leesbaarheid en duidelijkheid. Maar dat kan ook aan mij liggen hoor.

Nee, je hebt helemaal gelijk. Dit is een feature die ontzettend misbruikt gaat worden ben ik bang. Het gestelde voorbeeld helpt daar ook niet echt mee. Maar in specifieke (en juiste) gevallen kan het vrij handig zijn.

[ArmEagle]

Oh ja, ik mixte de twee samen. Die Asymmetric Property Visibility valt inderdaad juist mee.

[winkbrace]

Als ik eerlijk ben denk ik niet dat dat een feature is die ik zelf veel ga gebruiken. Ik schrijf al jaren bijna geen setters meer en public readonly is meestal precies wat ik nodig heb. Die ene keer dat een setter nodig is, ben ik liever expliciet. (Hmm, eens kijken hoe het met interfaces werkt)
array_find is denk ik de nuttigste nieuwe feature.

[peize9]

Sinds php7 zijn er echt veel verbeteringen gekomen in PHP, en ik ben benieuwd waar het verder naartoe gaat.

[FrankHe]

Met de stappen naar versie 7 en 8 begint PHP steeds meer strict en meer expliciet te worden waardoor het tegenwoordig niet meer kan worden afgedaan als een 'scriptingtaaltje'. Ook is de runtime onder de motorkap sterk verbeterd wat de performance ten goede komt.

[peize9]

Zeker, ik zou het zelf niet gebruiken voor een gigantisch systeem met microservices en vele duizende bezoekers, maar ik gebruik het wel voor kleinere tot medium websites. Laravel + Vue met Inertia en je hebt een lekkere stack voor een moderne veilige website.

[Ryangr0]

Waar zou je dan wel voor kiezen? Volgens mij heeft PHP inmiddels wel bewezen dat het erg goed is voor exact wat je hier beschrijft.

[peize9]

Go of Rust

[winkbrace]

We ontvangen op het werk duizenden requests per seconde die we afhandelen met een Laravel api. De meeste moderne talen kunnen dit prima aan. Wat een prachtige tijd om mee te maken!

[peize9]

Laravel kan het ook zeker, maar Go of Rust hebben toch de mogelijkheid om met minder server resources het zelfde resultaat te behalen.

[Webgnome]

Dat is dan ook Appels/Peren vergelijken. C/C++ is nog een stukje sneller en Assembly tja. Maar niemand gaat een heel web landschap in Assembly zitten kloppen of Rust for that matter ( als het anders is hoor ik dat graag ).

Wil je robuustheid etc dan zou je zelfs nog naar Java kunnen kijken ( J2ee bestaat dat nog ). Aantal grote banken gebruiken dat nog. En ja dat is performant..

[Reactie gewijzigd door Webgnome op 23 november 2024 07:11]

[_JGC_]

Die performance verbeteringen worden wat mij betreft heel erg overschat. Het grote verschil zit nog altijd in de code van de programmeur.
Wat ik heel veel tegenkom zijn repositories of factories die compleet verkeerd gebruikt worden. Bij elke call de database in en dan in een loopje 1 voor 1 die objecten ophalen bijvoorbeeld.

[FrankHe]

De runtime van PHP zelf is verbeterd maar externe I/O wordt natuurlijk niet sneller.

Hoe bedoel je precies "Bij elke call de database in en dan in een loopje 1 voor 1 die objecten ophalen bijvoorbeeld."? Dat is volgens mij hoe ORM werkt, alles uit de datalaag is in de code beschikbaar als objecten. Welke andere methode heb je voor ogen? Misschien begrijp ik het niet goed?

[_JGC_]

Stel je hebt een array met 10 product_ids en dan dit doet:
foreach($product_ids as $product_id) {
$product = $repo->getProductById($product_id);
// doe iets met $product
}

Vervolgens is getProductById een functie die een losse select op de database doet, dan heb je 10 losse queries naar de database.

Wat je ook kunt doen: die producten alle 10 met 1 query ophalen en dan in die $repo stoppen zodat je zonder extra queries die objecten terug kunt geven. Scheelt je 9 calls naar de database.

[Webgnome]

Want hoe is dat specifiek voor PHP? Dit kan in alle talen verkeerd gaan. Als je als junior dit doet dan kun je daar nog mee weg komen ( maar krijg je wel een review comment ) echter verder niet.

[Patriot]

Misschien had je even verder terug moeten lezen want dat het niet door PHP komt was juist het punt dat _JGC_ maakte

[Webgnome]

Ik las het als iets dat in PHP land veel vaker voor lijkt te komen... vandaar mijn reactie

[FrankHe]

Dat is geen probleem in PHP, dat is een probleem van bepaalde frameworks die op deze manier zijn gebouwd. De keuze daarvoor is ingegeven door het feit dat de data storage uitgewisseld kan worden. De winst is flexibiliteit ten koste van verlies aan performance. Maar dit komt niet door enige designkeuze in PHP zelf.

[_JGC_]

Klopt, maar waar ik vaak hoor dat PHP traag is, ligt het probleem eigenlijk altijd bij de programmeur.
Die snelheidsoptimalisaties in nieuwere PHP versies zijn maar een druppel op de gloeiende plaat voor heel veel websites.

Laatst zelf nog een website grondig verbouwd, factor 10 sneller gekregen. Puur door queries goed te combineren en meerdere objecten in 1x ophalen.
Vraag was of Googlebot nog meer kon spideren terwijl de server al ruim aan zijn max zat. Ik was verbaasd dat er nog zoveel te halen was.

[FrankHe]

Er zijn heel veel PHP implementaties die buitengewoon inefficiënt zijn gebouwd. Neem de gemiddelde WordPress site, die hebben vaak een stuk of 25 plug-ins en vele hooks waardoor een site belachelijk traag wordt. Dat is gewoon een architectuurkeuze die verkeerd is uitgepakt.

[CapnCrinkle]

Dat riep ik een tijdje terug ook, maar dat bleek niet helemaal correct te zijn.

Al deze features zijn vooralsnog optioneel.

Een klein aantal functies vereisen nu wel parameters welke dat voorheen niet deden, maar het was sowieso zeer zware bad practice om dit niet sowieso al te doen in de meeste gevallen.

Geen enkele van deze features vereisen dat je ze gebruikt dus het doet niet heel veel af aan de flexibiliteit. Ik heb nog projecten die in php 5.4 gebouwd zijn draaien op php 8.3 zonder issues.

[FrankHe]

Laat ik het anders formuleren, als je 'strict' wilt programmeren dan kan dat tegenwoordig met PHP, daar waar het er vroeger gewoonweg niet in zat. Backwards compatibility zal inderdaad voorlopig nog wel een ding blijven.

[Remzi1993]

Inderdaad, ben 10 jaar geleden gestopt met PHP en volledig overgegaan naar JavaScript, Typescript en Node.js en vele JS frameworks zoals Vue.js en React. Ik werd helemaal gek van die PHP en steeds servers die alleen hele oude PHP versie ondersteunen enz..

[Reactie gewijzigd door Remzi1993 op 21 november 2024 22:37]

[RobertMe]

En bij hoeveel hosters kun je Node.js draaien? Volgens mij is er geen enkele hosting partij waar je zo je .js / .ts files kunt uploaden. Oftewel: dan moet je met een eigen server aan de slag. En als je dat dan toch doet kun je net zo goed PHP zelf installeren. IMO dus een kul argument om PHP af te doen op basis van (shared) hosting partijen die een oude PHP versie leveren.

Nog los van dat de frameworks die je noemt frontend zijn (Vue.js & React). Dus je zit ook nog eens appels met peren te vergelijken. Want iets van data opslag kan al niet met de tech stack die je benoemd (ja, als je Node.js op een server hebt draaien kan dat, maar dan ben je terug bij punt 1, hosting) kan direct met een database of wat dan ook babbelen (ok, tenzij je letterlijk de database server (als in: MySQL / Postgresql / ...) open zet voor de weide wereld, zoals initieel met MongoDB werd gedaan, en nouja, MongoDB hoor je ook niks meer van, behalve als er weer eens duizenden servers zijn gevonden die volledig uitgelezen kunnen worden "via internet")).

En het JS / Node.js / npm / ... ecosysteem heeft ook vele kuren (gehad). Hoe packages geinstalleerd worden, incl. dependencies van dependencies die allemaal apart worden geinstalleerd i.p.v. "gedeeld". Packages die door een maintainer even * plop * offline worden gehaald waardoor het hele ecosysteem op zijn gat ligt. Packages met letterlijk 1 functie (str_left_pad), met vervolgens weer andere packages met 1 functie (str_right_pad). Dan werkt Composer aan de PHP kant toch echt stukken beter.

[FrankHe]

Feit is dat PHP 8.x gewoon een prima taal is om aanzienlijke systemen mee te draaien en de LAMP stack is de stack die verreweg het meest wordt gehost in de wereld. Dat er nog een hoop oude rommel draait is ontegenzeggelijk het geval maar dat is niet de schuld van PHP 8.x. Het bestaan van oude software is volledig de verantwoording van de mensen wiens taak het is de betreffende toepassingen te onderhouden.

Enkele jaren geleden heb ik eens een blik geworpen op het server side JS gebeuren maar had dat vervolgens vrij snel gezien en heb m'n tijd besteed aan het leren van de nieuwere PHP versies.

[vespino]

Kwestie van een fatsoenlijke hoster zoeken lijkt me?

[Webgnome]

Van de regen in de drup. Dat is wat ik eigenlijk eerst denk bij PHP -> Javascript. Waar PHP al jaren vorderingen maakt op het gebied van typing etc heeft Javascript iets nodig als typescript om het ook maar een beetje werkbaar te krijgen.
En dan heb ik het nog niet over ReactJS waarbij frontend en backend heerlijk door elkaar lopen. Dat doen we in PHP land al heel lang niet meer.

Dat er hosters zijn met verouderde versies? Ja dan huur je zelf een servertje en zet je er op wat je er zelf op wil zetten. Dat is geen reden om een bepaalde taal maar af te schieten

[Reactie gewijzigd door Webgnome op 21 november 2024 19:27]

[FrankHe]

De oplossing is simpel, een betere hoster zoeken of een managed VPS gebruiken waarbij je zelf in de hand hebt welke versie je draait. Wanneer je bij een webhoster zit die op dit moment nog steeds geen PHP 8.2 aanbiedt dan zou ik daar maar heel snel weggaan.

[thePiett]

Wat is er "piece of shit" aan Laravel en / of Livewire?

[imqqmi]

Dat is een oud beeld wat mensen hebben van PHP. Dat klopt allang niet meer.

Tja er zijn altijd issues met iedere tech stack die je gebruikt. Laravel is wel een bewezen framework, wat impliceert dat PHP dat zo langzamerhand ook is, zeker als je kijkt naar oplossingen zoals RHEL waar er security updates ook voor oudere versies van PHP zijn ook al is dat officieel niet meer ondersteund.

Frameworks in Javascipt land vallen zo snel in en uit de mode, dat is gewoon niet te doen.

[thePiett]

Thanks, ik gebruik Laravel dagelijks en vind het by far het beste / meest praktische PHP framework dus je hoeft mij niet te overtuigen

[Webgnome]

Frameworks in Javascipt land vallen zo snel in en uit de mode, dat is gewoon niet te doen.

Ook dat begint gelukkig steeds beter te worden. Vue/ReactJS zijn op dit moment toch echt wel de defacto standaard als het om frontend gaat ( zover ik kan overzien ). Er zijn er natuurlijk wel een hoop, maar dat kan ook gezegd worden van PHP. Er zijn in dat land nog steeds een groot aantal hobbybobs die vinden dat ze een nieuw CMS, CRM, Framework etc moeten opzetten en niet snappen dat die trein is gepasseerd en dat je je peilen beter kan richten op het ontwikkelen van libraries voor dingen.

[Webgnome]

Want wat is er precies verkeerd aan Laravel? Makkelijk scoren maar beargumenteren zou wel een ideetje zijn denk je niet?

[FrankHe]

Er is zeker nog een hoop oude rommel in omloop die nog op PHP 4 is gebouwd. Maar in de tussentijd is er echt een hele hoop gebeurt. PHP 8 is wat betreft typing veel dichter naar talen als C# en Java toegekropen. Bij PHP 8 kun je zonder meer stellen dat het meer robuust en krachtiger is dan de vorige versies.

[jnr24]

Lol, ik programmeer al sinds 1985, heel veel talen gezien (nooit echt zwaar professioneel), php vanaf het begin nog wel het meeste, maar ik heb echt geen flauw idee waar je het over hebt

[CapnCrinkle]

Ik moet je bekennen dat ik geen idee heb waar je op reageert?

Mogelijk bij de verkeerde comment op reply gedrukt?

[Solopher]

Kijk, we kunnen allemaal al over! De eerste .1 release is al uit . PHP 8.4.0 is namelijk overgeslagen

Het lijkt erop dat er nog niet echt veel Rector rules zijn, maar normaal kun je Rector gebruiken om snel je code te herschrijven naar bijv. PHP 8.4: https://github.com/rectorphp/rector (test je code wel goed, want er kunnen altijd breaking changes zijn )

[Remenic]

Op de officiële GitHub pagina van php is anders gewoon versie 8.4.0 te downloaden, sinds 2 dagen.

[Gustaaf437]

Klopt, ze taggen de release altijd een paar dagen voor de release. Als die versie dan stabiel is, dan wordt dat de uit te brengen versie Uiteindelijk bleken er toch nog wat last-minute (security) fixes nodig, zo te zien in hun repo, waardoor 8.4.1 de eerste officiële 8.4 release is geworden.