Software-update: PHP 8.1.0

Versie 8.1.0 van PHP is uitgebracht. 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.1.0 Released!

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

• Enumerations
• Readonly properties
• Fibers
• Pure Intersection Types
• never return type
• First-class Callable Syntax
• "final" modifier for class constants
• New fsync and fdatasync functions
• New array_is_list function
• Explicit Octal numeral notation
• And much much more...

Take a look at the PHP 8.1 Announcement Addendum for more information.

Versienummer	8.1.0
Releasestatus	Final
Besturingssystemen	Scripttaal, Windows 7, Linux, BSD, macOS, Solaris, UNIX, Windows Server 2008, Windows Server 2012, Windows 8, Windows 10, Windows Server 2016, Windows Server 2019, Windows 11
Website	Fabrikant
Download	https://www.php.net/downloads.php
Licentietype	Voorwaarden (GNU/BSD/etc.)

Reacties (38)

[Webgnome]

Ben toch wel blij met het toevoegen enums, final classes en readonly properties. Dat waren toch wel zaken die in elke andere taal gemeengoed zijn en wel eens werden gemist.

Wat ik mij alleen afvraag is, is het nut van de 'never' return? Dat lijkt mij een niet meer dan een handigheidje. Of is dit een implementatie van de 'void' van Java?

[thomasmoors]

Nee void zat er al in, never betekent vreemd genoeg dat de functie niet tot het einde van zijn scope moet komen (afsluitend haakje). Dus de functie wordt verwacht afgebroken te worden voor het eind. Void doet dat wel, maar returnt geen value (of null).

[Werelds]

Nee, het betekent niet dat de functie niet tot z'n afsluitende accolade ("}") komt. Het betekent dat de functie nooit terugkeert. Semantisch verschil, maar belangrijk voor statische analyse. Simpel voorbeeld:

function error(): never {
exit(-1);
}

doStuff();
error();
doMoreStuff();

Een static analyser kan nu detecteren dat doMoreStuff nooit wordt uitgevoerd en je dus waarschuwen dat je waarschijnlijk een bug in je code hebt, voorheen was dat vrij lastig. Voor de runtime maakt het geen reet uit, het is vooral voor statische analyse. IDE's als PhpStorm doen dit nu al met exit(), die() en dergelijke. En nu kan dat dus ook voor userland functies zonder PHPDoc hacks (@return noreturn).

Deze functies zijn allebei illegaal en zullen een error geven (fatal voor a(), type voor b()):

function a(string $param): never {
if ($param === '') {
return;
}
echo $param;
exit();
}

function b(string $param): never {
if ($param!== '') {
exit();
}

echo $param;
}

[Reactie gewijzigd door Werelds op 22 juli 2024 15:35]

[Veneus]

Je weet dat je nu juist een bug gemaakt hebt?
Als $param in je functie a nu een lege string is returned ie dus wel.
Dus niet never.

[Werelds]

Even de regel boven die quote (code blocks werken blijkbaar niet buiten GoT) lezen, a en b zullen nu allebei een error vanuit PHP geven

[Veneus]

Oeps sorry

[Webgnome]

Zag het inderdaad. Dat was toegevoegd in 7.1 blijkbaar. Maar zoals ook in een andere reactie, wat zou nu een praktisch voorbeeld zijn van het never return type?

[emnich]

Het voordeel is vooral dat static analyzers (en je IDE) beter snappen wat de functie doet en dus (potentiële) fouten kunnen opsporen

[bazzi]

Heb je daemon functies ofzo, is dit netter, want stopt nooit “normaal”

[eborn]

Wat ik mij alleen afvraag is, is het nut van de 'never' return? Dat lijkt mij een niet meer dan een handigheidje. Of is dit een implementatie van de 'void' van Java?

Het is vermoedelijk voor IDE's een handige tool om te bepalen of code klopt. Als je na een never-functie nog code hebt staan of geen try-catch gebruikt, dan kan de IDE daar melding van maken.

[SnakeSolidNL]

function redirectToLoginPage(): never {
    redirect('/login');
    echo 'Hello'; // <- dead code detected by static analysis
}

[air2]

Wat je in je uitleg mist is dat dit komt omdat redirect een never als return type heeft. De never in redirectToLoginPage() doet er in dit voorbeeld niet zoveel toe.

[SnakeSolidNL]

Het was slechts een voorbeeld, maar als je de RFC erop naleest is het iets duidelijker:

Redirect functions that always call exit (either explicitly or implicitly) are good candidates for such a return type:

function redirect(string $uri): noreturn {
header('Location: ' . $uri);
exit();
}

function redirectToLoginPage(): noreturn {
redirect('/login');
}

PHP developers can call these functions, safe in the knowledge that no statements after the function call will be evaluated:

function sayHello(?User $user) {
if (!$user) {
redirectToLoginPage();
}

echo 'Hello ' . $user->getName();
}

If, at some later date, the redirect function is changed so that it does sometimes return a value, a compile error is produced:

function redirect(string $uri): noreturn {
if ($uri === '') {
return; // Fatal error: A noreturn function must not return
}
header('Location: ' . $uri);
exit();
}

[noidea_2]

Eens. Maar in bijv PHPStorm kon je dit al langer aangeven in de file .phpstorm.meta.php met een exitPoint() definiëren (docs: https://www.jetbrains.com...a.html#define-exit-points).
Hetzelfde zit nu dus in de taal.

[basmilius]

En naast .phpstorm.meta.php was er ook een #[NoReturn] attribuut dat hetzelfde deed

[herovazy]

Never is bedoeld voor functies die het script eindigen. Bijvoorbeeld met een die() of die altijd een error throwen

[Webgnome]

Maar wat is daar dan in de praktijk het praktisch nut van? Puur ter informatie aan de ontwikkelaar? Anders kan ik het niet bedenken eerlijk gezegd. Vanuit de documentatie word ik er ook niet echt wijzer uit wanneer je dit zou willen gebruiken?

[Michali]

Het lijkt me voor statische code analyse tools als Psalm, PHPStan en Phan ook een fijne toevoeging. Die weten dan dat de flow op het punt van aanroepen van die functie stopt.

[herovazy]

Ja ik denk puur voor developers. Wanneer je een Never functie aanroept, zal je IDE dit waarschijnlijk aan gaan geven wanneer je code onder de aanroep plaatst.

Ik denk dat het vooral van meerwaarde is wanneer bij het interfacen. Daar vind ik het zelf altijd erg fijn als iedereen goed en duidelijk aangeeft wat de return types moeten zijn. Zo kan je in een oogopslag zien of de functie iets returnt, niets returnt en met deze toevoeging er voor zorgt dat je code beëindigd wordt.

[LauPro]

Het is een garantie dat de functie altijd zal eindigen.

Als je een complete functie hebt is er de kans dat je misschien met meerdere if-statements of cases tot een bepaalde conclusie komt. Mocht ergens exit() worden vergeten dan heb je kans dat deze functie elders doorloopt. Dat kan weer allemaal ongewenste consequenties hebben.

Dus een dergelijke never-keyword bij de functie garandeert dat de functie daarna stopt

[davekok]

Een functie bijvoorbeeld met een infinite loop. Waarin alle async io wordt afgehandeld en je fibers managed. Of de main functie van een fiber die aan het eind de fiber opruimt. Niet heel erg relevant.

[SnakeSolidNL]

A function or method declared with the never type indicates that it will not return a value and will either throw an exception or end the script’s execution with a call of die(), exit(), trigger_error(), or something similar.

[CH4OS]

De link over never in de tekst schrijft:

Never type
A new return only type never has been added. This indicates that a function either exit(), throws an exception, or doesn't terminate.

De RFC schaft wellicht meer duidelijkheid .

[Reactie gewijzigd door CH4OS op 22 juli 2024 15:35]

[MMaI]

PHP had al void. Never is toegevoegd als functie die expliciet een terminate actie (exit/die/exception) geeft. Zie ook https://php.watch/versions/8.1/never-return-type voor meer info

[Xorifelse]

Ben toch wel blij met het toevoegen enums, final classes en readonly properties.

Hier zijn altijd alternatieven voor geweest, final classes zaten al een tijdje in PHP 5 volgens mij read only kon je met magic setter en getter functions implementeren, maar nu kan het dus zonder overhead en enums en matching is inderdaad verfrissend om te zien.

Wat ik mij alleen afvraag is, is het nut van de 'never' return?

Geen, behalve dat je op de eerste lijn kan lezen wat deze functie kan verwachten en dat kan makkelijker lezen.

Of is dit een implementatie van de 'void' van Java?

Void is overgenomen van 'C' & 'C++', in andere "C-like-languages" zoals Java en PHP.

[Reactie gewijzigd door Xorifelse op 22 juli 2024 15:35]

[jaenster]

Never is meer een typescript dingtje.

Het aan kunnen geven dat een functie nooit iets terug geeft (aka een error gooit) zorgt er voor dat je type checking simpeler word.

Als je controleerd of een variable string is, en een functie induikt die voor jou een nette error generate, en dus nooit returned, kun je er vanuit gaan dat de rest van de code daaronder, de variable geen string is. Als dat immers zo is, duik je een functie in die ophoud met de code flow

[.Vii]

Ffiiibbbbbbeeerrssssss !

En enums, Nice.

[Reactie gewijzigd door .Vii op 22 juli 2024 15:35]

[noidea_2]

Fibers... ja, kan... Zit nog een hoop werk in voor de developer om goed te gebruiken. Threads is eigenlijk waar ik op wacht. Maar dat zal wel een paar dagen duren nog voordat dat er in zit...

[youri_ajax]

Ik weet niet of er ooit een “fatsoenlijke” thread implementatie komt? Omdat php eigenlijk altijd wel single threaded is?

[noidea_2]

Ik reken er niet op dat er een threads op afzienbare termijn komt.

[Ventieldopje]

Vaak wel maar lang niet altijd. Genoeg scenario's tegen gekomen die in PHP niet vooruit te branden zijn single threaded. Concurrency is dan toch wel erg fijn bijv als je dingen moet importeren/exporteren, dingen moet converteren etc.

Maar ik heb zelf de voorkeur die dingen allemaal in bijv C# te schrijven. Gaat allemaal een enorm stuk sneller

[Ventieldopje]

Eerder had je pthreads en nu parallel: https://www.php.net/manual/en/intro.parallel.php

Kan dus prima

[Jan-E]

https://github.com/krakjo...01#issuecomment-892442141

The fact is the future of parallel is in jeopardy because of fibers in core: The core has chosen a concurrency model and it doesn't accommodate threads. Fibers and parallel threads cannot interact with each other in a predictable way because of the way CSP is implemented in parallel. Some people think that's not a problem, but I disagree, I don't think you'll be able to make full use of either fibers or threads while the two cannot interact with each other.

I've heard a few people say that they would like me to continue to maintain parallel, including the author of the Fiber RFC and some of its supporters. However, I wrote parallel for inclusion into PHP, and today it looks like that is never going to happen.

I don't use parallel for anything personally, nor do I use it at work. I can't justify spending time on it.

I have a few sponsors on github but nowhere near enough to change my mind that this project is probably a dead end.

[Ventieldopje]

Yikes dat zou wel zonde zijn maar wel begrijpelijk. Maar afwachten hoe fibers in de praktijk gaan uitpakken.

[WarriorXK]

Ik vermoed niet dat threading ooit natively in PHP beschikbaar zal zijn. Er is al een lange tijd een PECL package voor threading, maar die werkt enkel in CLI context omdat het binnen een "embedded" context (Apache bvb) de boel goed in de war zou schoppen.

[jozuf]

Niet dat het hetzelfde is maar je kan ook forken waardoor je feitelijk op een andere thread draait voor de CPU.
Mist natuurlijk veel dingen die echt multithreaded wel kunnen.

[Verwijderd]

Ik dacht dat rondom Fibers een hele discussie was dat het een redelijk halve implementatie was vanuit een of ander houtje-touwtje team.

[Werelds]

Dat valt wel mee, het is meer dat een klein deel van de ontwikkelaars achter Swoole vinden dat hun werk beter is

Hun argument was dat fibers enkel nuttig voor AMPHP zijn (waar het werk vandaan komt), maar het grootste deel van de mailing list was het daar niet mee eens.