![\"PHP](\"https:\/\/kinsta.com\/wp-content\/uploads\/2020\/05\/php-8-released.png\")
Ben je er klaar voor? Aan de slag!<\/p>\n
PHP JIT (Just in Time Compiler)<\/h2>\n
De feature van PHP 8 waar de meeste mensen naar uitkijken is de Just-in-Time (JIT) compiler<\/strong>. Maar wat is JIT precies?<\/p>\n Het RFC voorstel<\/a> beschrijft JIT als volgt:<\/p>\n “PHP JIT is ge\u00efmplementeerd als een zo goed als onafhankelijk onderdeel van OPcache. Het kan voor de compileertijd en voor de looptijd van PHP worden ingeschakeld\/uitschakeld. Wanneer het is ingeschakeld, wordt de native code van PHP data in een extra regio van OPcache Shared Memory opgeslagen en zorgen op_array\u2192opcodes[].handler(s) voor verwijzigen naar de toegangspunten van ge-JIT-eerde code.”<\/p><\/blockquote>\n Maar hoe zijn we bij JIT aanbeland en wat is het verschil tussen JIT en OPcache?<\/p>\n Laten we, om de rol van JIT binnen PHP beter te begrijpen, eens kijken hoe PHP<\/a> zaken uitvoert: vanaf de broncode tot het uiteindelijke resultaat.<\/p>\n De PHP uitvoering is een proces in 4 fasen:<\/p>\n De volgende afbeelding toont een visuele weergave van het standaard PHP uitvoerproces.<\/p>\n Maar hoe maakt OPcache PHP nu sneller? En wat verandert er met JIT precies aan dit uitvoeringsproces?<\/p>\n PHP is een ge\u00efnterpreteerde taal. Dit betekent dat, wanneer een PHP script wordt uitgevoerd, de interpreter deze parsed (ontleedt), compileert en uitvoert. Dit gebeurt bij elk nieuw verzoek opnieuw en opnieuw. Het nadeel hiervan laat zich raden: de kans is groot dat je hierdoor tijd en CPU resources verspilt<\/a>.<\/p>\n Dit is waar de OPcache extensie<\/a> van pas komt:<\/p>\n “Opcache verbetert de prestaties van PHP door een voorgecompileerde script-bytecode in het Shared Memory op te slaan. Hierdoor vervalt voor PHP de noodzaak om bij elk verzoek scripts te laden en te parsen.”<\/p><\/blockquote>\n Met OPcache ingeschakeld doorloopt de PHP interpreter het bovengenoemde proces van 4 stappen alleen wanneer het script voor de eerste keer wordt uitgevoerd. Omdat PHP bytecodes in het Shared Memory worden opgeslagen, zijn ze meteen beschikbaar als een low-level intermediate representation en kunnen ze meteen op de Zend VM worden uitgevoerd.<\/p>\n Vanaf PHP 5.5 is de Zend OPcache extensie standaard beschikbaar. Je kan makkelijk controleren of je deze correct hebt geconfigureerd door Leessuggestie: Zo verhoog je de PHP geheugenlimiet in WordPress<\/a>.<\/p>\n OPcache is onlangs verbeterd met de toevoeging van preloading<\/a>, een nieuwe OPcache function die is toegevoegd in PHP 7.4<\/a>. Preloading biedt een manier om een opgegeven set scripts op te slaan in het OPcache geheugen “voordat welke applicatiecode dan ook wordt uitgevoerd<\/em>“, maar brengt geen significante verbeteringen voor typische webgebaseerde applicaties.<\/p>\n Je kan meer lezen over preloading in onze inleiding tot PHP 7.4<\/a>.<\/p>\n Met JIT zet PHP een stap vooruit..<\/p>\n Zelfs als opcodes de vorm hebben van intermediate representations, moeten ze nog steeds worden gecompileerd in machinecode. JIT “introduceert geen aanvullend IR (Intermediate Representation) formulier”, maar gebruikt DynASM<\/a> (Dynamic Assembler voor codegeneratie-engines) om uit PHP byte-code rechtstreeks native code te genereren.<\/p>\n Kortom, JIT vertaalt de “hete delen” van de intermediate code in machinecode<\/strong>. Door het compilatieproces over te slaan, zou het aanzienlijke verbeteringen in prestaties en geheugenverbruik kunnen betekenen.<\/p>\n Zeev Surasky, co-auteur van het PHP JIT voorstel, laat hoeveel sneller berekeningen zouden zijn met JIT:<\/p>\n Maar zou JIT ook de WordPress prestaties<\/a> effectief kunnen verbeteren?<\/p>\n Volgens de JIT RFC zou de implementatie van de Just-in-Time Compiler de prestaties van PHP moeten verbeteren. Maar zouden we dergelijke verbeteringen ook daadwerkelijk ervaren binnen real-life apps als WordPress?<\/p>\n De eerste tests tonen inderdaad aan dat JIT CPU intensieve workloads aanzienlijk versnelt, maar de RFC waarschuwt<\/a>:<\/p>\n “… net als de vorige pogingen – het lijkt er momenteel niet op dat het significante verbeteringen brengt aan real-life apps als WordPress (met opcache.jit=1235 326 req\/sec vs 315 req\/sec).<\/p>\n Het is de bedoeling dat we hiermee nog verder aan de slag gaan, om JIT te verbeteren voor real-life apps met behulp van profiling en speculatieve optimalisaties.”<\/p><\/blockquote>\n Wanneer JIT is ingeschakeld, wordt de code niet uitgevoerd door Zend VM, maar door de CPU zelf. Dit zou de berekeningssnelheid moeten verbeteren. Web apps als WordPress<\/a> zijn ook afhankelijk van andere factoren als TTFB<\/a>, database-optimalisatie<\/a>, HTTP verzoeken<\/a>, etc.<\/p>\n We hoeven dus geen significante verbetering te verwachten in de snelheid waarmee PHP wordt uitgevoerd als het gaat om WordPress en vergelijkbare apps. Toch kan JIT, met name voor ontwikkelaars<\/a>, verschillende voordelen met zich meebrengen.<\/p>\n Volgens Nikita Popov<\/a>:<\/p>\n “De voordelen van de JIT Compiler zijn grofweg (en zoals al beschreven in de RFC):<\/p>\n Dus hoewel JIT nauwelijks noemenswaardige verbeteringen zal brengen wat betreft WordPress prestaties, tilt het wel PHP naar het volgende niveau, waarmee het een taal wordt waar veel functions nu rechtstreeks in kunnen worden geschreven.<\/p>\n Het nadeel is wel dat de grotere complexiteit kan leiden tot hogere kosten voor onderhoud<\/a>, stabiliteit en debugging<\/a>. Volgens Mitry Stogov:<\/p>\n “JIT is uiterst eenvoudig, maar het verhoogt wel het complexiteitsniveau van PHP als geheel, met een verhoogd risico op nieuwe soorten bugs en een hogere kosten voor ontwikkeling en onderhoud.”<\/p><\/blockquote>\n Het voorstel om JIT op te nemen in PHP 8 werd aangenomen met 50 stemmen voor en 2 stemmen tegen.<\/p>\n\n Naast JIT kunnen we veel andere functions en verbeteringen verwachten met PHP 8. De volgende lijst is een zorgvuldig samengestelde selectie van de aankomende toevoegingen en wijzigingen die PHP betrouwbaarder en effici\u00ebnter moeten gaan maken.<\/p>\n Als gevolg van een voortdurende discussie over hoe we object ergonomics in PHP<\/a> kunnen verbeteren, stelt de Constructor Property Promotion RFC<\/a> een nieuwe en beknoptere syntax voor die de property declaration simplificeert, waardoor deze korter en zinvoller wordt.<\/p>\n Dit voorstel heeft alleen betrekking op promoted parameters<\/strong>, dwz de method parameters met de visibility keywords public<\/strong>, protected<\/strong> en private<\/strong> als prefix.<\/p>\n Momenteel moeten alle property’s meerdere keren herhaald worden (minimaal vier keer) voordat we ze met objects kunnen gebruiken. Kijk eens naar het volgende voorbeeld uit de RFC:<\/p>\n Volgens Nikita Popov, de bedenker van de RFC, moeten we de property name minstens vier keer op drie verschillende plaatsen neerzetten: de property declaration, de constructor parameters en de property assignment. Deze syntax is niet erg bruikbaar, vooral niet in classes met een groot aantal property’s en meer beschrijvende namen.<\/p>\n Deze RFC stelt voor om de constructor en de parameter definition samen te voegen. Vanaf PHP 8 gaan we dus beschikken we dus over een meer bruikbare manier om parameters te declareren en kan je de bovenstaande code veranderen in wat je hieronder ziet:<\/p>\n En dat was het al. We hebben dus de beschikking over een nieuwe manier om property’s te promoten: korter, beter leesbaar en minder foutgevoelig. Volgens Nikita<\/a>:<\/p>\n Het is een kleine syntactische transformatie die we hier voorstellen. Maar het vermindert wel de hoeveelheid code die je moet schrijven voor met name value objects…<\/p><\/blockquote>\n De property declaration wordt getransformeerd aangezien we deze property’s al expliciet hebben gedeclared. We kunnen de Reflection API<\/a> gebruiken om de property definitions v\u00f3\u00f3r de uitvoering te introspecten (zie Sesugaring<\/a>):<\/p>\n Reflection (en andere andere introspectionmechanismen) observeren de state na desugaring. Dit betekent dat de promoted property’s er hetzelfde uitzien als expliciet gedeclarede property’s en promoted constructor arguments verschijnen dus als ordinary constructor arguments.<\/p><\/blockquote>\n We hebben geen beperkingen opgesteld bij het gebruik van inheritance in combinatie met promoted parameters. Hoe dan ook, er is specifieke relatie tussen constructors van parent en child class. Volgens Nikita<\/a>:<\/p>\n Meestal zeggen we dat methoden altijd compatibel moeten zijn met de bovenliggende methode. […] maar deze regel is niet van toepassing op de constructor. De constructor behoort dus echt tot een single class en constructors tussen parent en child class hoeven op geen enkele manier compatibel te zijn.<\/p><\/blockquote>\n Dit is een voorbeeld:<\/p>\n Promoted property’s zijn toegestaand in non-abstract constructors en traits, maar er zijn een aantal beperkingen die het vermelden waard zijn.<\/p>\n Promoted property’s zijn niet toegestaan in abstract classes en interfaces:<\/p>\n Een van de meest opvallende beperkingen houdt verband met nullability. Eerder, wanneer we een type gebruikten dat niet expliciet nullabel was, maar die wel een null als default value had, dan was het type impliciet nullabel. Maar met property types hebben we dit impliciete gedrag niet, omdat promoted parameters een property declaration vereisen. Het nullable type moet dus expliciet gedeclared worden. Bekijk het onderstaande voorbeeld van de RFC:<\/p>\n Aangezien “callable” geen property type is dat wordt ondersteund<\/a>, mogen we geen callable type gebruiken in promoted property’s:<\/p>\n Alleen een visibility keyword kan worden gebruikt met promoted parameters, dus het declaren van constructor property’s met het We kunnen promoted property’s en explicit property’s combineren binnen dezelfde class, maar property’s kunnen niet twee keer worden gedeclared:<\/p>\n De reden is dat het declared type verschilt van de variadic parameters, wat eigenlijk een array is:<\/p>\n Als je meer wil weten over Constructor Property Promoted, luister dan naar dit interview met Nikita Popov<\/a>. Voor een uitgebreid overzicht van object ergonomics in PHP, zie dit artikel<\/a> en het volgende interview met Larry Garfield<\/a>.<\/p>\n Traits<\/a> worden gedefinieerd als “een mechanisme voor hergebruik van code in single-inheritance talen als PHP”. Normaal gesproken worden ze gebruikt om methods vast te leggen die in meerdere classes kunnen worden gebruikt.<\/p>\n Een trait kan ook abstract methods bevatten. Deze methods leggen alleen de signature van de method vast, de implementatie van de method moet binnen de class worden gedaan met behulp van de trait.<\/p>\n Volgens de PHP handleiding<\/a>,<\/p>\n “Traits ondersteunen het gebruik van abstract methods om eisen te stellen aan de exhibiting class.”<\/p><\/blockquote>\n Dit betekent ook dat de signatures van de methods overeen moeten komen. Met andere woorden, het type en het aantal vereiste arguments moeten hetzelfde zijn<\/a>.<\/p>\n Hoe dan ook, volgens de auteur van de RFC, Nikita Popov<\/a>, wordt de signature-validatie momenteel alleen sporadisch afgedwongen:<\/p>\n Het volgende voorbeeld van Nikia heeft betrekking op het eerste geval (de niet-afgedwongen signature):<\/p>\n Dat gezegd hebbende, deze RFC<\/a> stelt voor om altijd een fatal error te geven wanneer de implementing method niet compatibel is met de abstract trait method, ongeacht de oorsprong:<\/p>\n Deze RFC is unaniem goedgekeurd.<\/p>\n In PHP veroorzaken inheritance errors als gevolg van incompatibele method signatures een fatal error of een waarschuwing, afhankelijk van wat de fout veroorzaakt.<\/p>\n Als een class een interface implementeert, dan veroorzaken incompatibele method signatures een fatal error. Volgens de Oject Interfaces documentatie<\/a>:<\/p>\n “De class die de interface implementeert moet een method signature gebruiken die compatibel is met LSP (Liskov Substitution Principle). Als je dit niet doet, krijg je een fatal error.”<\/p><\/blockquote>\n Dit is een voorbeeld van een inheritance error met een interface<\/a>:<\/p>\n In PHP 7.4 zou de bovenstaande code de volgende error opleveren:<\/p>\n Een function in een child class met een incompatible signature zou een error geven. Bekijk de volgende code van de RFC:<\/p>\n In PHP 7.4 zou de bovenstaande code alleen een waarschuwing geven:<\/p>\n Deze RFC<\/a> gaat een stapje verder en stelt voor om een fatal error te genereren voor incompatibele method signatures. Met PHP 8 zou de code die we eerder zagen het volgende oproepen:<\/p>\n Als een array in PHP begint met een negatieve index ( In PHP 7.4 zou dit resulteren in het volgende:<\/p>\n Deze RFC<\/a> stelt hierin een wijziging voor, zodat de tweede index In PHP zou bovenstaande code dus resulteren in de volgende array:<\/p>\n Met PHP vertonen arrays die beginnen met een negatieve index dus ander gedrag. Lees meer over backward incompatibilities in de RFC<\/a> zelf.<\/p>\n Untion types<\/a> accepteren values die van verschillende types kunnen zijn. Momenteel biedt PHP geen ondersteuning voor union types, met uitzondering van de Voor PHP 8 konden union types alleen worden gespecificeerd in phpdoc annotations, zoals je kan zien in het onderstaande voorbeeld van de RFC:<\/p>\n De RFC Union Types 2.0<\/a> stelt voor om ondersteuning voor union types toe te voegen in function signatures, zodat we niet meer afhankelijk zijn van inline documentatie, maar nu union types kunnen defini\u00ebren met een Dit wordt uitgelegd door Nikita Popov in de RFC,<\/p>\n “Door in de taal union types te ondersteunen kunnen we meer type information verplaatsen van phpdoc naar function signatures, met de gebruikelijke voordelen die dit met zich meebrengt:<\/p>\n Union types ondersteunen alle beschikbare types, met enkele beperkingen:<\/p>\n Je kan in het RFC meer lezen over Union Types V2<\/a>..<\/p>\n Wanneer een parameter van een illegaal type wordt doorgegeven, gedragen internal<\/a> en user-define<\/a> functions zich anders.<\/p>\n User-defined functions veroorzaken een Dit zou de volgende waarschuwing opgeven:<\/p>\n Als Deze situatie zou leiden tot een aantal problemen. Dit wordt uitvoerig uitgelegd in de Issues sectie van de RFC<\/a>.<\/p>\n Om deze inconsistenties te verwijderen, stelt deze RFC voor<\/a> om de internal parameter die API’s parseert altijd een Fatal error: Uncaught TypeError: strlen(): Argument #1 ($str) must be of type string, object given in \/path\/to\/your\/test.php:4<\/p>\n In PHP is Deze RFC<\/a> stelt voor om het Bekijk de volgende voorbeelden van de RFC:<\/p>\n Een weak map is een collectie van data (objects) waarin keys weakly referenced zijn. Dit voorkomt dat ze garbaged collected worden.<\/p>\n PHP 7.4 voegde ondersteuning toe voor weak references<\/a> als een manier om een reference naar een object te behouden, maar dat niet verhindert dat het object zelf wordt vernietigd. Zoals Nikita Popov opmerkte,<\/p>\n “Raw weak references zijn op zichzelf van beperkt nut en weak maps worden in de praktijk veel vaker gebruikt. Het is niet mogelijk om een effici\u00ebnte weak map bovenop PHP weak references te implementeren, omdat de mogelijkheid om een destruction callback te registreren niet wordt geboden.”<\/p><\/blockquote>\n Dat is waarom deze RFC<\/a> een WeakMap class introduceert om objects te maken die kunnen worden gebruikt als weak map keys. Deze kunnen worden vernietigd en verwijderd van de weak map als er geen verdere verwijzingen zijn naar het key object.<\/p>\n In langlopende processen zou dit memory leaks kunnen voorkomen en prestaties kunnen verbeteren. Bekijk het onderstaande voorbeeld van de RFC:<\/p>\n Met PHP zou de bovenstaande code het volgende resultaat opleveren (zie de code hier in actie<\/a>):<\/p>\n Als je het object unset, wordt de key automatisch uit de weak map verwijderd:<\/p>\n Nu zou het resultaat het volgende zijn:<\/p>\n Voor meer informatie over Weak Maps kan je het best de RFC<\/a> lezen. Het voorstel was unaniem goedgekeurd.<\/p>\n Trailing commas zijn komma’s die zijn toegevoegd aan lijsten met items in verschillende contexten. PHP 7.2 introduceerde trailing commas in list syntax<\/a> en PHP 7.3 introduceerde trailing commas in function calls<\/a>.<\/p>\n PHP introduceert nu trailing commas in parameter lists<\/a> met functions, methods en closures. In onderstaand voorbeeld kan je meer zien:<\/p>\n\n
![\"Standaard](\"https:\/\/kinsta.com\/nl\/wp-content\/uploads\/sites\/7\/2020\/05\/php-uitvoeringsproces.png\")
De OPcache extensie<\/h3>\n
phpinfo()<\/code> aan te roepen<\/a> vanuit een script op je server of door je php.ini bestand te checken (zie OPcache configuratie-instellingen<\/a>).<\/p>\n![\"Zend](\"https:\/\/kinsta.com\/nl\/wp-content\/uploads\/sites\/7\/2020\/05\/zend-opcache.jpg\")
Preloading<\/h3>\n
JIT \u2014 The Just in Time Compiler<\/h3>\n
JIT voor Live Web Apps<\/h3>\n
![\"Relatieve](\"https:\/\/kinsta.com\/wp-content\/uploads\/2020\/05\/php-8-performance-diagram.png\")
\n
Verbeteringen en nieuwe functions PHP 8<\/h2>\n
Constructor Property Promotion<\/h3>\n
class Point {\n public int $x;\n public int $y;\n public int $z;\n\n public function __construct(\n int $x = 0,\n int $y = 0,\n int $z = 0,\n ) {\n $this->x = $x;\n $this->y = $y;\n $this->z = $z;\n }\n}<\/code><\/pre>\nclass Point {\n public function __construct(\n public int $x = 0,\n public int $y = 0,\n public int $z = 0,\n ) {}\n}<\/code><\/pre>\n\/\/ before desugaring\nclass Point {\n public function __construct(public int $x = 0) {}\n}\n\n\/\/ after desugaring\nclass Point {\n public int $x;\n\n public function __construct(int $x = 0) {\n $this->x = $x;\n }\n}<\/code><\/pre>\nInheritance<\/h4>\n
class Test {\n public function __construct(\n public int $x = 0\n ) {}\n}\n\nclass Child extends Test {\n public function __construct(\n $x, \n public int $y = 0,\n public int $z = 0,\n ) {\n parent::__construct($x);\n }\n}<\/code><\/pre>\nWat niet toegestaan is bij promoted property’s<\/h4>\n
Abstract constructors<\/h5>\n
abstract class Test {\n \/\/ Error: Abstract constructor.\n abstract public function __construct(private $x);\n}\n \ninterface Test {\n \/\/ Error: Abstract constructor.\n public function __construct(private $x);\n}<\/code><\/pre>\nNullability<\/h5>\n
class Test {\n \/\/ Error: Using null default on non-nullable property\n public function __construct(public Type $prop = null) {}\n\n \/\/ Correct: Make the type explicitly nullable instead\n public function __construct(public ?Type $prop = null) {}\n}<\/code><\/pre>\nCallable Type<\/h5>\n
class Test {\n \/\/ Error: Callable type not supported for properties.\n public function __construct(public callable $callback) {}\n}<\/code><\/pre>\nThe var Keyword Is Not Allowed<\/h5>\n
var<\/code> keyword is niet toegestaan (zie het onderstaande voorbeeld van de RFC):<\/p>\nclass Test {\n \/\/ Error: \"var\" keyword is not supported.\n public function __construct(var $prop) {}\n}<\/code><\/pre>\nNo Duplications Allowed<\/h5>\n
class Test {\n public string $prop;\n public int $explicitProp;\n\n \/\/ Correct\n public function __construct(public int $promotedProp, int $arg) {\n $this->explicitProp = $arg;\n }\n\n \/\/ Error: Redeclaration of property.\n public function __construct(public string $prop) {}\n}<\/code><\/pre>\nVariadic Parameters Are Not Allowed<\/h5>\n
class Test {\n \/\/ Error: Variadic parameter.\n public function __construct(public string ...$strings) {}\n}<\/code><\/pre>\nVerder lezen<\/h4>\n
Validatie voor abstract trait methods<\/h3>\n
\n
trait T {\n\tabstract public function test(int $x);\n}\n \nclass C {\n\tuse T;\n\n\t\/\/ Allowed, but shouldn't be due to invalid type.\n\tpublic function test(string $x) {}\n}<\/code><\/pre>\nFatal error: Declaration of C::test(string $x) must be compatible with T::test(int $x) in \/path\/to\/your\/test.php on line 10<\/code><\/pre>\nIncompatibele method signatures<\/h3>\n
interface I {\n\tpublic function method(array $a);\n}\nclass C implements I {\n\tpublic function method(int $a) {}\n}<\/code><\/pre>\nFatal error: Declaration of C::method(int $a) must be compatible with I::method(array $a) in \/path\/to\/your\/test.php on line 7<\/code><\/pre>\nclass C1 {\n\tpublic function method(array $a) {}\n}\nclass C2 extends C1 {\n\tpublic function method(int $a) {}\n}<\/code><\/pre>\nWarning: Declaration of C2::method(int $a) should be compatible with C1::method(array $a) in \/path\/to\/your\/test.php on line 7<\/code><\/pre>\nFatal error: Declaration of C2::method(int $a) must be compatible with C1::method(array $a) in \/path\/to\/your\/test.php on line 7<\/code><\/pre>\nArrays beginnend met een negatieve index<\/h3>\n
start_index <0<\/code>), dan beginnen de indices erna vanaf 0 (meer hierover in array_fill documentatie<\/a>). Dit wordt toegelicht in het volgende voorbeeld:<\/p>\n$a = array_fill(-5, 4, true);\nvar_dump($a);<\/code><\/pre>\narray(4) {\n\t[-5]=>\n\tbool(true)\n\t[0]=>\n\tbool(true)\n\t[1]=>\n\tbool(true)\n\t[2]=>\n\tbool(true)\n}<\/code><\/pre>\nstart_index +1<\/code> zou zijn, ongeacht de value van start_index<\/code>.<\/p>\narray(4) {\n\t[-5]=>\n\tbool(true)\n\t[-4]=>\n\tbool(true)\n\t[-3]=>\n\tbool(true)\n\t[-2]=>\n\tbool(true)\n}<\/code><\/pre>\nUnion types 2.0<\/h3>\n
?Type<\/code> syntax en special type iterable<\/code>.<\/p>\nclass Number {\n\t\/**\n\t * @var int|float $number\n\t *\/\n\tprivate $number;\n\n\t\/**\n\t * @param int|float $number\n\t *\/\n\tpublic function setNumber($number) {\n\t\t$this->number = $number;\n\t}\n\n\t\/**\n\t * @return int|float\n\t *\/\n\tpublic function getNumber() {\n\t\treturn $this->number;\n\t}\n}<\/code><\/pre>\nT1|T2|<\/code>… syntax:<\/p>\nclass Number {\n\tprivate int|float $number;\n\n\tpublic function setNumber(int|float $number): void {\n\t\t$this->number = $number;\n\t}\n\n\tpublic function getNumber(): int|float {\n\t\treturn $this->number;\n\t}\n}<\/code><\/pre>\n\n
\n
void<\/code> type kan geen deel uitmaken van een union, omdat void<\/code> inhoudt dat een function geen enkele value retourneert<\/a>.<\/li>\nnull<\/code> type wordt uitsluitend ondersteund in union types, maar gebruik ervan als een standalone type is niet toegestaan.<\/li>\n?T<\/code>) is ook toegestaan, wat T|null<\/code> Het is echter niet toegestaan om de ?T notatie op te nemen in union types (?T1|T2<\/code> is niet toegestaan en we moeten dus in plaats daarvan T1|T2|null<\/code> gebruiken).<\/li>\nstrpos()<\/code>, strstr()<\/code>, substr()<\/code> false bevatten als mogelijke return types, wordt het pseudo-type false ook ondersteund.<\/li>\n<\/ul>\nConsistent type errors voor internal functions<\/h3>\n
TypeError<\/code>, maar internal functions gedragen zich op verschillende manieren, afhankelijk van verschillende voorwaarden. Hoe dan ook, het typische antwoord is om een waarschuwing te geven en een null<\/code> te retourneren. Zie het onderstaande voorbeeld in PHP 7.4:<\/p>\nvar_dump(strlen(new stdClass));<\/code><\/pre>\nWarning: strlen() expects parameter 1 to be string, object given in \/path\/to\/your\/test.php on line 4\nNULL<\/code><\/pre>\nstrict_types<\/code> is ingeschakeld of argument information types specificeert, dan zien we ander gedrag. In dergelijke scenario’s wordt de type error gedetecteerd en resulteert het in een TypeError<\/code>.<\/p>\nThrowError<\/code> te laten genereren in het geval een parameter type niet overeenkomt.<\/p>\nFatal error: Uncaught TypeError: strlen(): Argument #1 ($str) must be of type string, object given in \/path\/to\/your\/test.php:4\nStack trace:\n#0 {main}\n thrown in \/path\/to\/your\/test.php on line 4<\/code><\/pre>\nthrow Expression<\/h3>\n
throw<\/code> een statement<\/a>. Het is dus niet mogelijk om deze te gebruiken op plekken waar alleen een expression<\/a> is toegestaan.<\/p>\nthrow<\/code> statement<\/a> om te zetten in een expression zodat deze ook kan worden gebruikt in context waarin expressions zijn toegestaan. Denk hierbij aan arrow functions<\/a>, null coalesce operator<\/a>, ternary en elvis operators<\/a>, etc.<\/p>\n$callable = fn() => throw new Exception();\n\n\/\/ $value is non-nullable.\n$value = $nullableValue ?? throw new InvalidArgumentException();\n \n\/\/ $value is truthy.\n$value = $falsableValue ?: throw new InvalidArgumentException();<\/code><\/pre>\nWeak Maps<\/h3>\n
$map = new WeakMap;\n$obj = new stdClass;\n$map[$obj] = 42;\nvar_dump($map);<\/code><\/pre>\nobject(WeakMap)#1 (1) {\n\t[0]=>\n\tarray(2) {\n\t\t[\"key\"]=>\n\t\tobject(stdClass)#2 (0) {\n\t\t}\n\t\t[\"value\"]=>\n\t\tint(42)\n\t}\n}<\/code><\/pre>\nunset($obj);\nvar_dump($map);<\/code><\/pre>\nobject(WeakMap)#1 (0) {\n}<\/code><\/pre>\nTrailing comma in parameter list<\/h3>\n