![\"PHP](\"https:\/\/kinsta.com\/wp-content\/uploads\/2020\/05\/php-8-released.png\")
Er du klar? Lad os dykke ned!<\/p>\n
PHP JIT (Just in Time Compiler)<\/h2>\n
Den mest anerkendte funktion, der f\u00f8lger med PHP 8, er Just-in-time (JIT)\u00a0 Compiler. Hvad handler JIT om?<\/p>\n
RFC forslaget<\/a> beskriver JIT som f\u00f8lgende:<\/p>\n \u201dPHP JIT implementeres som en n\u00e6sten uafh\u00e6ngig del af OPcache. Det kan v\u00e6re aktiveret \/ deaktiveret p\u00e5 PHP compile tid og ved k\u00f8rselstidspunkt. N\u00e5r det er aktiveret, gemmes oprindelig kode for PHP-filer i en yderligere region i den OPCache delte hukommelse og op_array \u2192 opcodes[]. Handler(e) holder pegepunkter til indgangspunkterne for JIT-ed-kode. \u201d<\/p><\/blockquote>\n S\u00e5 hvordan kom vi til JIT, og hvad er forskellen mellem JIT vs OPcache?<\/p>\n For bedre at forst\u00e5, hvad JIT er til PHP, s\u00e5 lad os se hurtigt p\u00e5, hvordan PHP<\/a> k\u00f8rer fra kildekoden til det endelige resultat.<\/p>\n PHP-udf\u00f8relsen er en 4-trins proces:<\/p>\n Det f\u00f8lgende billede viser en visuel repr\u00e6sentation af den grundl\u00e6ggende PHP-eksekveringsproces.<\/p>\n S\u00e5 hvordan g\u00f8r OPcache PHP hurtigere? Og hvilke \u00e6ndringer i udf\u00f8relsesprocessen med JIT?<\/p>\n PHP er et tolket sprog. Dette betyder, at n\u00e5r et PHP-script k\u00f8rer, tolker, kompilerer og udf\u00f8rer tolken koden igen og igen p\u00e5 hver anmodning. Dette kan resultere i spild af CPU-ressourcer<\/a> og ekstra tid.<\/p>\n Det er her en OPcache extension<\/a> kommer i spil:<\/p>\n “OPcache forbedrer PHP-ydeevne ved at gemme forudkompileret script-bytecode i delt hukommelse og dermed fjerne behovet for PHP at indl\u00e6se og analysere scripts p\u00e5 hver anmodning.”<\/p><\/blockquote>\n Med OPcache aktiveret gennemg\u00e5r PHP-fortolkeren kun 4-trinsprocessen n\u00e6vnt ovenfor, n\u00e5r scriptet k\u00f8rer for f\u00f8rste gang. Da PHP-bytekoder gemmes i delt hukommelse, er de straks tilg\u00e6ngelige som mellemliggende repr\u00e6sentation p\u00e5 lavt niveau og kan udf\u00f8res med det samme p\u00e5 Zend VM.<\/p>\n Fra PHP 5.5 er en Zend OPcache extension tilg\u00e6ngelig som standard, og du kan kontrollere, om du har den korrekt konfigureret ved blot at kalde<\/a> Foresl\u00e5et l\u00e6sning: How to Improve PHP Memory Limit in WordPress<\/a>.<\/p>\n OPcache er for nylig blevet forbedret med implementeringen af preloading<\/a>, en ny OPcache-funktion tilf\u00f8jet med PHP 7.4<\/a>. Forudindl\u00e6sning giver en m\u00e5de at gemme et specificeret s\u00e6t scripts i OPcache-hukommelse \u201cf\u00f8r en applikationskode k\u00f8res\u201d, men det medf\u00f8rer ikke konkrete ydelse-forbedringer for typiske webbaserede applikationer.<\/p>\n Du kan l\u00e6se mere om preloading i vores introduktion til PHP 7.4<\/a>.<\/p>\n Med JIT bev\u00e6ger PHP sig et skridt fremad.<\/p>\n Selv hvis opcodes er i form af mellemliggende repr\u00e6sentation p\u00e5 lavt niveau, skal de stadig samles til maskinkode. JIT “introducerer ikke nogen yderligere IR (Mellem-repr\u00e6sentation) -formular”, men bruger DynASM<\/a> (Dynamic Assembler til kodegenereringsmotorer) til at generere native code direkte fra PHP-byte-kode.<\/p>\n Kort sagt, JIT overs\u00e6tter de varme dele af den mellemliggende kode til maskinkode<\/strong>. Ved at omg\u00e5 kompilering kunne det medf\u00f8re betydelige forbedringer i performance og hukommelsesforbrug.<\/p>\n Zeev Surasky, medforfatter til PHP JIT-forslaget, viser, hvor meget beregninger der ville v\u00e6re hurtigere med JIT:<\/p>\n Men ville JIT effektivt forbedre WordPress performance<\/a>?<\/p>\n I henhold til JIT RFC, skal implementeringen af \u200b\u200bjust in time compiler forbedre PHP performance. Men ville vi virkelig opleve s\u00e5danne forbedringer i virkelige apps som WordPress?<\/p>\n De tidlige test viser, at JIT ville f\u00e5 CPU-intensive arbejdsbelastninger til at k\u00f8re betydeligt hurtigere, men RFC advarer<\/a>:<\/p>\n \u201d… ligesom de foreg\u00e5ende fors\u00f8g – det ser ud til, at det i \u00f8jeblikket ikke markant forbedrer apps i det virkelige liv som WordPress (med opcache.jit=1235 326 req\/sek vs 315 req\/sek).<\/p>\n Det er planlagt at give en ekstra indsats, forbedre JIT til apps i det virkelige liv, ved hj\u00e6lp af profilering og spekulative optimeringer.\u201d<\/p><\/blockquote>\n N\u00e5r JIT er aktiveret, k\u00f8res koden ikke af Zend VM, men af \u200b\u200bselve CPU’en, og dette ville forbedre hastigheden i beregningen. Webapps som WordPress<\/a> er ogs\u00e5 afh\u00e6ngige af andre faktorer som TTFB<\/a>, databaseoptimering<\/a>, HTTP-anmodninger<\/a> osv.\u00fa<\/p>\n S\u00e5 vi skal ikke forvente et markant l\u00f8ft i PHP-udf\u00f8relseshastigheden, n\u00e5r det kommer til WordPress og lignende apps. Ikke desto mindre kunne JIT give flere fordele for udviklere<\/a>.<\/p>\n If\u00f8lge Nikita Popov<\/a>:<\/p>\n \u201dFordelene ved JIT-kompilatoren er nogenlunde (og som allerede beskrevet i RFC):<\/p>\n S\u00e5 selvom JIT n\u00e6ppe vil bringe enorme forbedringer af WordPress-ydeevne, vil den opgradere PHP til det n\u00e6ste niveau, hvilket g\u00f8r det til et sprog, hvor mange funktioner nu kunne skrives direkte p\u00e5.<\/p>\n Ulempen er dog den st\u00f8rre kompleksitet, der kan f\u00f8re til stigende omkostninger til vedligeholdelse<\/a>, stabilitet og debugging<\/a>. If\u00f8lge Dmitry Stogov:<\/p>\n \u201dJIT er ekstremt simpelt, men alligevel \u00f8ger det niveauet for hele PHP-kompleksiteten, risikoen for ny slags bugs og omkostningerne til udvikling og vedligeholdelse.\u201d<\/p><\/blockquote>\n Forslaget om at medtage JIT i PHP 8 blev vedtaget med 50 til 2 stemmer.<\/p>\n\n Bortset fra JIT kan vi forvente mange funktioner og forbedringer med PHP 8. Den f\u00f8lgende liste er vores h\u00e5ndplukkede valg af de kommende tilf\u00f8jelser og \u00e6ndringer, der skal g\u00f8re PHP mere p\u00e5lidelig og effektiv.<\/p>\n Som et resultat af en l\u00f8bende diskussion om, hvordan man forbedrer object ergonomics i PHP<\/a>, foresl\u00e5r Constructor Property Promotion RFC<\/a> en ny og mere kortfattet syntaks, der vil forenkle ejendomserkl\u00e6ringen, hvilket g\u00f8r den kortere og mindre overfl\u00f8dig.<\/p>\n Dette forslag vedr\u00f8rer kun promoverede parametre<\/strong>, dvs. de metode-parametre, der er pr\u00e6fixet med offentlige<\/strong>, beskyttede<\/strong> og private<\/strong> synlige keywords.<\/p>\n I \u00f8jeblikket skal alle egenskaber gentages flere gange (mindst fire gange), f\u00f8r vi kan bruge dem med objekter. Overvej f\u00f8lgende eksempel fra RFC\u00a0:<\/p>\n If\u00f8lge Nikita Popov, forfatteren af \u200b\u200bRFC, er vi n\u00f8dt til at skrive ejendomsnavnet mindst fire gange p\u00e5 tre forskellige steder: ejendomserkl\u00e6ringen, konstrukt\u00f8rparametrene og egenskabsopgaven. Denne syntaks er ikke s\u00e6rlig anvendelig, is\u00e6r i klasser med et godt antal egenskaber og mere beskrivende navne.<\/p>\n Denne RFC foresl\u00e5r at flette konstrukt\u00f8ren og parameterdefinitionen. S\u00e5 fra PHP 8 har vi en mere anvendelig m\u00e5de at erkl\u00e6re parametre, og koden set ovenfor kan \u00e6ndres som vist nedenfor:<\/p>\n Og det er det. S\u00e5 vi har en ny m\u00e5de at markedsf\u00f8re egenskaber, der er kortere, mere l\u00e6selige og mindre tilb\u00f8jelige til fejl. If\u00f8lge Nikita<\/a>:<\/p>\n Det er en simpel syntaktisk transformation, som vi laver. Men det reducerer m\u00e6ngden af kedelplade-kode, du er n\u00f8dt til at skrive for v\u00e6rdiobjekter is\u00e6r …<\/p><\/blockquote>\n Ejendomserkl\u00e6ringen transformeres, da vi eksplicit havde erkl\u00e6ret disse egenskaber, og vi kan bruge Reflection-API<\/a> til at introspektere egenskabsdefinitioner f\u00f8r udf\u00f8relsen (se Desugaring<\/a>):<\/p>\n Reflektion (og andre introspektionsmekanismer) vil observere tilstanden efter desugaring. Dette betyder, at promoverede egenskaber vises p\u00e5 samme m\u00e5de som eksplicit deklarerede egenskaber, og promoverede konstrukt\u00f8rargumenter vises som almindelige konstrukt\u00f8rargumenter.<\/p><\/blockquote>\n Vi har ingen begr\u00e6nsninger i brugen af \u200b\u200barv sammen med promoverede parametre. Under alle omst\u00e6ndigheder er der ikke et bestemt forhold mellem for\u00e6ldre og child class construction. If\u00f8lge Nikita<\/a>:<\/p>\n Normalt siger vi, at metoder altid skal v\u00e6re kompatible med den overordnede metode. […] men denne regel g\u00e6lder ikke for konstrukt\u00f8ren. S\u00e5 konstrukt\u00f8ren h\u00f8rer virkelig til en enkelt klasse, og konstrukt\u00f8rer mellem for\u00e6ldre og b\u00f8rn klasse beh\u00f8ver ikke at v\u00e6re kompatible p\u00e5 nogen m\u00e5de.<\/p><\/blockquote>\n Her er et eksempe:<\/p>\n Fremme egenskaber er tilladt i ikke-abstrakte konstrukt\u00f8rer og tr\u00e6k, men der er flere begr\u00e6nsninger, der er v\u00e6rd at n\u00e6vne her.<\/p>\n Promoverede egenskaber er ikke tilladt i abstrakte klasser og gr\u00e6nseflader:<\/p>\n En af de mest bem\u00e6rkelsesv\u00e6rdige begr\u00e6nsninger er relateret til nullability. Tidligere, da vi brugte en type, der ikke var eksplicit nullable, men med en nul standardv\u00e6rdi, var typen implicit nullable. Men med egenskabstyper har vi ikke denne implicitte opf\u00f8rsel, fordi promoverede parametre kr\u00e6ver en ejendomserkl\u00e6ring, og den nullable type skal eksplicit erkl\u00e6res. Se f\u00f8lgende eksempel fra RFC:<\/p>\n Da konverterbar ikke er en underst\u00f8ttet type for egenskaber<\/a>, har vi ikke tilladelse til at bruge den konverterbare type i promoverede egenskaber\u00a0:<\/p>\n Kun et synligt keyword kan bruges med promoverede parametre, s\u00e5 det er ikke tilladt at erkl\u00e6re konstrukt\u00f8regenskaber med Vi kan kombinere promoverede egenskaber og eksplicitte egenskaber i samme klasse, men egenskaber kan ikke erkl\u00e6res to gange\u00a0:<\/p>\n \u00c5rsagen her er, at den erkl\u00e6rede type adskiller sig fra den variadiske parameter, som faktisk er en matrix\u00a0:<\/p>\n For at se n\u00e6rmere p\u00e5 Costructor Property Promotion, lyt til dette interview med Nikita Popov<\/a>. For et dybt overblik over object ergonomics i PHP, se dette indl\u00e6g<\/a> og f\u00f8lgende interview med Larry Garfield<\/a>.<\/p>\n Traits<\/a> er defineret som “en mekanisme til genanvendelse af kode p\u00e5 enkelt arvsprog som PHP”. Typisk bruges de til at erkl\u00e6re metoder, der kan bruges i flere klasser.<\/p>\n En egenskab kan ogs\u00e5 indeholde abstrakte metoder. Disse metoder erkl\u00e6rer simpelthen metodens signatur, men metodens implementering skal ske inden for klassen ved hj\u00e6lp af egenskaben.<\/p>\n I henhold til PHP-manualen<\/a><\/p>\n “Traits underst\u00f8tter brugen af \u200b\u200babstrakte metoder til at stille krav til exhibiting class.”<\/p><\/blockquote>\n Dette betyder ogs\u00e5, at signaturer til metoderne skal matche. Med andre ord skal typen og antallet af n\u00f8dvendige argumenter v\u00e6re den samme<\/a>.<\/p>\n I hvert fald h\u00e5ndh\u00e6ves signatur-validering if\u00f8lge Nikita Popov<\/a>, forfatter af RFC, i \u00f8jeblikket kun spottet:<\/p>\n F\u00f8lgende eksempel fra Nikita vedr\u00f8rer den f\u00f8rste sag (ikke h\u00e5ndh\u00e6vet underskrift):<\/p>\n N\u00e5r det er sagt, foresl\u00e5r denne RFC<\/a> altid at kaste en d\u00f8delig fejl, hvis implementeringsmetoden ikke er kompatibel med den abstrakte egenskabsmetode, uanset dens oprindelse:<\/p>\n Denne RFC er enstemmig godkendt.<\/p>\n I PHP kaster arvefejl p\u00e5 grund af inkompatible metode-signaturer enten en d\u00f8delig fejl eller en advarsel afh\u00e6ngigt af, hvad der for\u00e5rsager fejlen.<\/p>\n Hvis en klasse implementerer en gr\u00e6nseflade, kaster ukompatible metode-signaturer en d\u00f8delig fejl. I henhold til Object Interfaces documentation<\/a>:<\/p>\n \u201dKlassen, der implementerer gr\u00e6nsefladen, skal bruge en metode-signatur, der er kompatibel med LSP (Liskov Substitution Principle). Hvis du ikke g\u00f8r det, vil det medf\u00f8re en d\u00f8delig fejl. \u201d<\/p><\/blockquote>\n Her er et eksempel p\u00e5 en arvefejl med en gr\u00e6nseflade<\/a>:<\/p>\n I PHP 7.4 ville koden ovenfor kaste f\u00f8lgende fejl:<\/p>\n En funktion i en child class med en inkompatibel signatur ville kaste en advarsel. Se f\u00f8lgende kode fra RFC:<\/p>\n I PHP 7.4 ville koden ovenfor blot kaste en advarsel:<\/p>\n Nu foresl\u00e5r denne RFC<\/a> altid at kaste en d\u00f8delig fejl ved underskrifter med inkompatibel metode. Med PHP 8 ville den kode, vi s\u00e5 tidligere ovenfor, bede om f\u00f8lgende:<\/p>\n I PHP, hvis en matrix starter med et negativt indeks ( I PHP 7.4 ville resultatet v\u00e6re f\u00f8lgende:<\/p>\n Nu foresl\u00e5r denne RFC<\/a> at \u00e6ndre ting, s\u00e5 det andet indeks ville v\u00e6re I PHP 8 ville koden ovenfor resultere i f\u00f8lgende array:<\/p>\n Med PHP 8 \u00e6ndrer arrays der begynder med et negativt indeks deres opf\u00f8rsel. L\u00e6s mere om bagudkompatibiliteter i RFC<\/a>.<\/p>\n Union types<\/a> accepterer v\u00e6rdier, der kan v\u00e6re af forskellige typer. I \u00f8jeblikket yder PHP ikke support til fagtyper med undtagelse af syntaks F\u00f8r PHP 8 kunne union types kun specificeres i phpdoc-kommentarer, som vist i f\u00f8lgende eksempel fra RFC:<\/p>\n Nu foresl\u00e5r the Union types 2.0 RFC<\/a> at tilf\u00f8je support til union types i funktionssignaturer, s\u00e5 vi ikke vil stole p\u00e5 inline-dokumentation mere, men vil definere union types med en Som forklaret af Nikita Popov i RFC,<\/p>\n \u201dAt st\u00f8tte fagforeningstyper p\u00e5 sproget giver os mulighed for at flytte flere typeoplysninger fra phpdoc til funktionsunderskrifter med de s\u00e6dvanlige fordele, dette medf\u00f8rer:<\/p>\n Union types underst\u00f8tter alle tilg\u00e6ngelige typer med nogle begr\u00e6nsninger:<\/p>\n Du kan l\u00e6se mere om union types V2<\/a> i RFC.<\/p>\n N\u00e5r du sender en parameter af ulovlig type, opf\u00f8rer de interne og brugerdefinerede funktioner sig forskelligt.<\/p>\n Brugerdefinerede funktioner kaster en Dette ville resultere i f\u00f8lgende advarsel:<\/p>\n Hvis Denne situation ville f\u00f8re til en r\u00e6kke problemer, der er godt forklaret i RFC’s problemafdeling<\/a>.<\/p>\n For at fjerne disse uoverensstemmelser foresl\u00e5r denne RFC<\/a> at oprette de interne parameter-parsing-API’er til altid at generere en I PHP 8 kaster koden ovenfor f\u00f8lgende fejl:<\/p>\n I PHP er Denne RFC<\/a> foresl\u00e5r at konvertere Se f\u00f8lgende eksempler fra RFC:<\/p>\n Et weak map er en samling af data (objekter), hvor n\u00f8gler refereres svagt, hvilket betyder, at de ikke forhindres i at blive opsamlet skrald.<\/p>\n PHP 7.4 tilf\u00f8jede st\u00f8tte til weak references<\/a> som en m\u00e5de at bevare en henvisning til et objekt, der ikke forhindrer selve objektet i at blive \u00f8delagt. Som p\u00e5peget af Nikita Popov,<\/p>\n \u201dR\u00e5 svage referencer er kun af begr\u00e6nset brugbarhed i sig selv, og weak maps er meget mere almindeligt anvendt i praksis. Det er ikke muligt at implementere et effektivt weak map oven p\u00e5 PHP-svage referencer, fordi der ikke er mulighed for at registrere et destruction callback. \u201d<\/p><\/blockquote>\n Derfor introducerer denne RFC<\/a> en I langvarige processer ville dette forhindre hukommelse l\u00e6kager og forbedre ydelsen. Se f\u00f8lgende eksempel fra RFC:<\/p>\n Med PHP 8 ville koden ovenfor give f\u00f8lgende resultat (se koden i action her)<\/a>:<\/p>\n Hvis du fjerner objektet, fjernes n\u00f8glen automatisk fra weak map:<\/p>\n Nu ville resultatet v\u00e6re f\u00f8lgende:<\/p>\n Se RFC for et n\u00e6rmere kig p\u00e5 weak mapst. Forslaget blev enstemmigt godkendt.<\/p>\n Trailing commas er kommaer knyttet til lister over elementer i forskellige sammenh\u00e6nge. PHP 7.2 introducerede trailing commas i listesyntaks<\/a>, PHP 7.3 introducerede trailing commas i function calls<\/a>.<\/p>\n PHP 8 introducerer nu trailing commas i parameter lists<\/a> med funktioner, metoder og lukninger, som vist i f\u00f8lgende eksempel:<\/p>\n\n
![\"Grundl\u00e6ggende](\"https:\/\/kinsta.com\/dk\/wp-content\/uploads\/sites\/12\/2020\/05\/php-eksekveringsproces-1.png\")
OPcache extension<\/h3>\n
![\"PHP](\"https:\/\/kinsta.com\/dk\/wp-content\/uploads\/sites\/12\/2020\/05\/php-eksekvering-2.png\")
phpinfo()<\/code><\/a> fra et script p\u00e5 din server eller tjekke din php.ini-fil (se OPcache-konfigurationsindstillinger<\/a>).<\/p>\n![\"Zend](\"https:\/\/kinsta.com\/dk\/wp-content\/uploads\/sites\/12\/2020\/05\/zend-opcache.jpg\")
Preloading<\/h3>\n
JIT \u2014 The Just in Time Compiler<\/h3>\n
JIT for Live Web Apps<\/h3>\n
![\"PHP](\"https:\/\/kinsta.com\/wp-content\/uploads\/2020\/05\/php-8-performance-diagram.png\")
\n
PHP 8 forbedringer og nye features<\/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>\nHvad der ikke er tilladt med promoverede egenskaber<\/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 (se f\u00f8lgende eksempel fra RFC)\u00a0:<\/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>\nYderligere l\u00e6sninger<\/h4>\n
Validering af abstrakte egenskabsmetoder<\/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>\nInkompatible metodetegn<\/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 der starter med et negativt indeks<\/h3>\n
start_index <0<\/code>), starter de f\u00f8lgende indekser fra 0 (mere om dette i array_fill<\/code><\/a><\/code> dokumentation<\/a>). Se p\u00e5 f\u00f8lgende eksempel:<\/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>, uanset v\u00e6rdien af 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> og den specielle iterable<\/code> type.<\/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> syntaks i stedet:<\/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 underst\u00f8ttes kun i union types, men det er ikke tilladt at bruge den som en selvst\u00e6ndig type<\/a>.<\/li>\nnull<\/code> type af \u200b\u200bden nullable type (?T<\/code>) er ogs\u00e5 tilladt, hvilket betyder T|null<\/code>, men vi har ikke tilladelse til at medtage?T<\/code>-notationen i union types (?T1|T2<\/code> er ikke tilladt, og vi b\u00f8r i stedet bruge T1|T2|null<\/code>) .<\/li>\nstrpos()<\/code>, strstr()<\/code>, substr()<\/code> osv.) Inkluderer falsk blandt de mulige returtyper, underst\u00f8ttes den false<\/code> pseudo type ogs\u00e5.<\/li>\n<\/ul>\nKonsistente typefejl til interne funktioner<\/h3>\n
TypeError<\/code>, men interne funktioner opf\u00f8rer sig p\u00e5 forskellige m\u00e5der, afh\u00e6ngigt af flere forhold. Alligevel er den typiske opf\u00f8rsel at smide en advarsel og returnere null<\/code>. Se f\u00f8lgende eksempel i 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> er aktiveret, eller hvis argument oplysninger specificerer typer, vil adf\u00e6rden v\u00e6re anderledes. I s\u00e5danne scenarier registreres typefejlen og resulterer i en TypeError<\/code>.<\/p>\nThrowError<\/code> i tilf\u00e6lde af en parametertilpasning.<\/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> en statement<\/a>, s\u00e5 det er ikke muligt at bruge det p\u00e5 steder, hvor kun en expression<\/a> er tilladt.<\/p>\nthrow<\/code> statement<\/a>\u00a0 til et udtryk, s\u00e5 det kan bruges i enhver sammenh\u00e6ng, hvor udtryk er tilladt. For eksempel arrow functions<\/a>, null coalesce operator<\/a>, ternary og elvis operators<\/a> osv.<\/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
WeakMap<\/code>-klasse for at oprette objekter, der kan bruges som svage weak map keys, der kan \u00f8del\u00e6gges og fjernes fra weak map, hvis der ikke er yderligere henvisninger til n\u00f8gleobjektet.<\/p>\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 commas i parameterliste<\/h3>\n