![\"PHP](\"https:\/\/kinsta.com\/wp-content\/uploads\/2020\/05\/php-8-released.png\")
Voc\u00ea est\u00e1 pronto? Vamos come\u00e7ar!<\/p>\n
PHP JIT (compilador Just in Time)<\/h2>\n
A caracter\u00edstica mais aclamada que vem com o PHP 8 \u00e9 o compilador Just-in-time (JIT)<\/strong>. Do que se trata o JIT?<\/p>\n A proposta da RFC<\/a> descreve o JIT da seguinte forma:<\/p>\n “O PHP JIT \u00e9 implementado como uma parte quase independente do OPcache. Ele pode ser habilitado\/desabilitado em tempo de compila\u00e7\u00e3o e em tempo de execu\u00e7\u00e3o do PHP. Quando habilitado, o c\u00f3digo nativo dos arquivos PHP \u00e9 armazenado em uma regi\u00e3o adicional da mem\u00f3ria compartilhada do OPcache e op_array\u2192opcodes[].handler(s) mant\u00e9m apontadores para os pontos de entrada do c\u00f3digo JIT-ed”<\/p><\/blockquote>\n Ent\u00e3o, como chegamos ao JIT, e qual \u00e9 a diferen\u00e7a entre JIT vs OPcache?<\/p>\n Para entender melhor o que \u00e9 JIT para PHP, vamos dar uma r\u00e1pida olhada em como o PHP<\/a> executa o c\u00f3digo fonte at\u00e9 o resultado final.<\/p>\n A execu\u00e7\u00e3o do PHP \u00e9 um processo de 4 etapas:<\/p>\n A imagem a seguir mostra uma representa\u00e7\u00e3o visual do processo b\u00e1sico de execu\u00e7\u00e3o do PHP.<\/p>\n Ent\u00e3o, como o OPcache torna o PHP mais r\u00e1pido? E que mudan\u00e7as no processo de execu\u00e7\u00e3o com o JIT?<\/p>\n PHP \u00e9 uma linguagem interpretada. Isto significa que, quando um script PHP \u00e9 executado, o int\u00e9rprete analisa, compila e executa o c\u00f3digo uma e outra vez a cada solicita\u00e7\u00e3o. Isto pode resultar em desperd\u00edcio de recursos da CPU<\/a> e tempo adicional.<\/p>\n \u00c9 aqui que entra a extens\u00e3o OPcache<\/a> para jogar:<\/p>\n “OPcache melhora a performance do PHP ao armazenar bytecode de script pr\u00e9-compilado na mem\u00f3ria compartilhada, removendo assim a necessidade do PHP carregar e analisar scripts em cada solicita\u00e7\u00e3o”<\/p><\/blockquote>\n Com o OPcache ativado, o interpretador PHP passa pelo processo de 4 etapas mencionado acima apenas quando o script \u00e9 executado pela primeira vez. Como os bytecodes PHP s\u00e3o armazenados em mem\u00f3ria compartilhada, eles est\u00e3o imediatamente dispon\u00edveis como representa\u00e7\u00e3o intermedi\u00e1ria de baixo n\u00edvel e podem ser executados na Zend VM imediatamente.<\/p>\n A partir do PHP 5.5, a extens\u00e3o Zend OPcache est\u00e1 dispon\u00edvel por padr\u00e3o, e voc\u00ea pode verificar se voc\u00ea a tem configurada corretamente, simplesmente ligando para Leitura sugerida: Como melhorar o limite de mem\u00f3ria PHP no WordPress<\/a>.<\/p>\n OPcache foi recentemente melhorado com a implementa\u00e7\u00e3o do pr\u00e9-carregamento<\/a>, um novo recurso OPcache adicionado com PHP 7.4<\/a>. O pr\u00e9-carregamento fornece uma maneira de armazenar um conjunto espec\u00edfico de scripts na mem\u00f3ria OPcache“antes que qualquer c\u00f3digo do aplicativo seja executado”<\/em>. “Ainda assim, ele n\u00e3o traz melhorias tang\u00edveis de performance para aplicativos t\u00edpicas baseadas na web.<\/p>\n Voc\u00ea pode ler mais sobre pr\u00e9-carrgamento em nossa introdu\u00e7\u00e3o ao PHP 7.4<\/a>.<\/p>\n Com o JIT, o PHP d\u00e1 um passo \u00e0 frente.<\/p>\n Mesmo que os opcodes sejam de baixo n\u00edvel de representa\u00e7\u00e3o intermedi\u00e1ria, eles ainda t\u00eam que ser compilados em c\u00f3digo de m\u00e1quina. JIT “n\u00e3o introduz nenhuma forma adicional IR (Intermediate Representation)”, mas usa DynASM<\/a> (Dynamic Assembler for code generation engines) para gerar c\u00f3digo nativo diretamente do byte-c\u00f3digo PHP.<\/p>\n Em resumo, o JIT traduz as partes quentes do c\u00f3digo intermedi\u00e1rio em c\u00f3digo de m\u00e1quina<\/strong>. Contornando a compila\u00e7\u00e3o, ele seria capaz de trazer melhorias consider\u00e1veis na performance e uso de mem\u00f3ria.<\/p>\n Zeev Surasky, co-autor da proposta PHP JIT, mostra o quanto os c\u00e1lculos seriam mais r\u00e1pidos com o JIT:<\/p>\n Mas, o JIT efetivamente melhoraria o desempenho do WordPress<\/a>?<\/p>\n De acordo com a RFC do JIT, a implementa\u00e7\u00e3o do compilador just in time deve melhorar o desempenho do PHP. Mas realmente experimentar\u00edamos tais melhorias em aplicativos da vida real como WordPress?<\/p>\n Os primeiros testes mostram que o JIT faria com que as cargas de trabalho intensivas da CPU funcionassem significativamente mais r\u00e1pido. No entanto, o RFC adverte<\/a>:<\/p>\n “… como as tentativas anteriores – atualmente n\u00e3o parece melhorar significativamente aplicativos da vida real como WordPress (com opcache.jit=1235 326 req\/sec vs 315 req\/sec).<\/p>\n Est\u00e1 previsto um esfor\u00e7o adicional, melhorando o JIT para aplicativos em tempo real, usando perfis e otimiza\u00e7\u00f5es especulativas”<\/p><\/blockquote>\n Com o JIT habilitado, o c\u00f3digo n\u00e3o seria executado pela Zend VM, mas pela pr\u00f3pria CPU, o que melhoraria a velocidade de c\u00e1lculo. Aplicativos Web como WordPress<\/a> tamb\u00e9m dependem de outros fatores como TTFB<\/a>, otimiza\u00e7\u00e3o de banco de dados<\/a>, solicita\u00e7\u00f5es HTTP<\/a>, etc.<\/p>\n Portanto, n\u00e3o devemos esperar um aumento significativo na velocidade de execu\u00e7\u00e3o do PHP quando se trata de WordPress e aplicativos semelhantes. No entanto, o JIT poderia trazer v\u00e1rios benef\u00edcios para os desenvolvedores<\/a>.<\/p>\n De acordo com Nikita Popov<\/a>:<\/p>\n “Os benef\u00edcios do compilador JIT s\u00e3o, (e como j\u00e1 foi delineado no RFC):<\/p>\n Ent\u00e3o, enquanto o JIT dificilmente trar\u00e1 grandes melhorias na performance do WordPress, ele estar\u00e1 atualizando o PHP para o pr\u00f3ximo n\u00edvel, fazendo dele uma linguagem na qual muitas fun\u00e7\u00f5es poderiam agora ser escritas diretamente.<\/p>\n O lado negativo seria a maior complexidade que pode aumentar a manuten\u00e7\u00e3o<\/a>, estabilidade e custos de depura\u00e7\u00e3o<\/a>. De acordo com Dmitry Stogov:<\/p>\n “O JIT \u00e9 extremamente simples, mas de qualquer forma ele aumenta o n\u00edvel de toda a complexidade do PHP, o risco de novos tipos de bugs e o custo de desenvolvimento e manuten\u00e7\u00e3o”<\/p><\/blockquote>\n A proposta de incluir o JIT no PHP 8 foi aprovada com 50 a 2 votos.<\/p>\n\n Al\u00e9m do JIT, n\u00f3s podemos esperar muitas funcionalidades e melhorias com o PHP 8. A lista a seguir \u00e9 nossa sele\u00e7\u00e3o das pr\u00f3ximas adi\u00e7\u00f5es e mudan\u00e7as que devem tornar o PHP mais confi\u00e1vel e eficiente.<\/p>\n Como resultado de uma discuss\u00e3o cont\u00ednua sobre a melhoria da ergonomia dos objetos em PHP<\/a>, a Constructor Property Promotion RFC<\/a> prop\u00f5e uma nova e mais concisa sintaxe que simplificar\u00e1 a declara\u00e7\u00e3o de propriedade, tornando-a mais curta e menos redundante.<\/p>\n Esta proposta se refere apenas aos par\u00e2metros promovidos<\/strong>, ou seja, aqueles par\u00e2metros do m\u00e9todo prefixados com palavras-chave de visibilidade \u00a0public<\/strong>,\u00a0protected<\/strong>, e private<\/strong>.<\/p>\n Atualmente, todas as propriedades t\u00eam que ser repetidas v\u00e1rias vezes (pelo menos quatro vezes) antes que possamos us\u00e1-las com objetos. Considere o seguinte exemplo da RFC:<\/p>\n De acordo com Nikita Popov, a autora do RFC, n\u00f3s temos que escrever o nome da propriedade pelo menos quatro vezes em tr\u00eas lugares diferentes: a declara\u00e7\u00e3o da propriedade, os par\u00e2metros do construtor e a atribui\u00e7\u00e3o da propriedade. Esta sintaxe n\u00e3o \u00e9 particularmente utiliz\u00e1vel, especialmente em classes com muitas propriedades e nomes mais descritivos.<\/p>\n Esta RFC se prop\u00f5e a fundir o construtor e a defini\u00e7\u00e3o dos par\u00e2metros. Assim, a partir do PHP 8, n\u00f3s temos uma maneira mais utiliz\u00e1vel de declarar par\u00e2metros. O c\u00f3digo visto acima pode mudar como mostrado abaixo:<\/p>\n E \u00e9 isso a\u00ed. Ent\u00e3o n\u00f3s temos uma nova maneira de promover propriedades que s\u00e3o mais curtas, mais leg\u00edveis, e menos propensas a erros. De acordo com Nikita<\/a>:<\/p>\n \u00c9 uma simples transforma\u00e7\u00e3o sint\u00e1tica que estamos fazendo. Mas isso reduz a quantidade de c\u00f3digo de placa de caldeira que voc\u00ea tem que escrever para objetos de valor em particular…<\/p><\/blockquote>\n A declara\u00e7\u00e3o de propriedade \u00e9 transformada como t\u00ednhamos declarado explicitamente essas propriedades, e podemos usar a API Reflection<\/a> para introspectar defini\u00e7\u00f5es de propriedade antes da execu\u00e7\u00e3o (veja Desugaring<\/a>):<\/p>\n Reflection (e outros mecanismos de introspec\u00e7\u00e3o) observar\u00e1 o estado ap\u00f3s o desugaring. Isto significa que as propriedades promovidas aparecer\u00e3o da mesma forma que as propriedades explicitamente declaradas, e os argumentos dos construtores promovidos aparecer\u00e3o como argumentos dos construtores comuns.<\/p><\/blockquote>\n N\u00f3s n\u00e3o temos nenhuma limita\u00e7\u00e3o no uso da heran\u00e7a em conjunto com os par\u00e2metros promovidos. De qualquer forma, n\u00e3o h\u00e1 uma rela\u00e7\u00e3o particular entre pais e filhos construtores de classes. De acordo com Nikita<\/a>:<\/p>\n Normalmente, n\u00f3s dizemos que os m\u00e9todos sempre t\u00eam que ser compat\u00edveis com o m\u00e9todo dos pais. […] mas esta regra n\u00e3o se aplica para o construtor. Ent\u00e3o o construtor realmente pertence a uma \u00fanica classe, e construtores entre classe pai e crian\u00e7a n\u00e3o t\u00eam que ser compat\u00edveis de nenhuma forma.<\/p><\/blockquote>\n Aqui est\u00e1 um exemplo:<\/p>\n As propriedades promovidas s\u00e3o permitidas em construtores n\u00e3o abstratos e funcionalidades, mas h\u00e1 v\u00e1rias limita\u00e7\u00f5es que vale a pena mencionar aqui.<\/p>\n Propriedades promovidas n\u00e3o s\u00e3o permitidas em classes e interfaces abstratas:<\/p>\n Uma das restri\u00e7\u00f5es mais not\u00e1veis est\u00e1 relacionada \u00e0 nulidade. Anteriormente, n\u00f3s us\u00e1vamos um tipo que n\u00e3o era explicitamente anul\u00e1vel. Mas com um valor padr\u00e3o nulo, o tipo era implicitamente anul\u00e1vel. Mas com tipos de propriedade, n\u00f3s n\u00e3o temos este comportamento impl\u00edcito porque os par\u00e2metros promovidos requerem uma declara\u00e7\u00e3o de propriedade, e o tipo nulo deve ser declarado explicitamente. Veja o seguinte exemplo da RFC:<\/p>\n Como o tipo cham\u00e1vel n\u00e3o \u00e9 um tipo suportado para propriedades<\/a>, n\u00e3o estamos autorizados a usar o tipo cham\u00e1vel em propriedades promovidas:<\/p>\n Somente uma palavra-chave de visibilidade pode ser usada com par\u00e2metros promovidos, portanto n\u00e3o \u00e9 permitido declarar propriedades do construtor com a palavra-chave N\u00f3s podemos combinar propriedades promovidas e propriedades expl\u00edcitas na mesma classe, mas as propriedades n\u00e3o podem ser declaradas duas vezes:<\/p>\n A raz\u00e3o aqui \u00e9 que o tipo declarado \u00e9 diferente do par\u00e2metro vari\u00e1dico, que na verdade \u00e9 um array:<\/p>\n Para uma vis\u00e3o mais pr\u00f3xima na Costructor Property Promotion, ou\u00e7a esta entrevista com Nikita Popov<\/a>. Para uma vis\u00e3o aprofundada da ergonomia dos objetos em PHP, veja este post<\/a> e a seguinte entrevista com Larry Garfield<\/a>.<\/p>\n Os tra\u00e7os<\/a> s\u00e3o definidos como “um mecanismo para reutiliza\u00e7\u00e3o de c\u00f3digo em linguagens de heran\u00e7a \u00fanica, como PHP” Tipicamente, eles s\u00e3o usados para declarar m\u00e9todos que podem ser usados em m\u00faltiplas classes.<\/p>\n Um tra\u00e7o tamb\u00e9m pode conter m\u00e9todos abstratos. Estes m\u00e9todos simplesmente declaram a assinatura do m\u00e9todo, mas a implementa\u00e7\u00e3o deve ser feita dentro da classe que utiliza o tra\u00e7o.<\/p>\n De acordo com o manual PHP<\/a>,<\/p>\n “Tra\u00e7os apoiam o uso de m\u00e9todos abstratos a fim de impor exig\u00eancias \u00e0 classe expositora”<\/p><\/blockquote>\n Isto tamb\u00e9m significa que as assinaturas dos m\u00e9todos devem coincidir. Em outras palavras, o tipo e o n\u00famero de argumentos requeridos precisam ser os mesmos<\/a>.<\/p>\n De qualquer forma, de acordo com Nikita Popov<\/a>, autora do RFC, a valida\u00e7\u00e3o da assinatura \u00e9 atualmente aplicada apenas de forma pontual:<\/p>\n O seguinte exemplo de Nikita se refere ao primeiro caso (assinatura n\u00e3o for\u00e7ada):<\/p>\n Dito isto, esta RFC<\/a> prop\u00f5e sempre lan\u00e7ar um erro fatal se o m\u00e9todo de implementa\u00e7\u00e3o n\u00e3o for compat\u00edvel com o m\u00e9todo do tra\u00e7o abstrato, independentemente de sua origem:<\/p>\n Esta RFC foi aprovada por unanimidade.<\/p>\n Em PHP, erros de heran\u00e7a devido a assinaturas de m\u00e9todos incompat\u00edveis lan\u00e7am ou um erro fatal ou um aviso, dependendo do que est\u00e1 causando o erro.<\/p>\n Se uma classe est\u00e1 implementando uma interface, assinaturas de m\u00e9todos incompat\u00edveis lan\u00e7am um erro fatal. De acordo com a documenta\u00e7\u00e3o da interface de objetos<\/a>:<\/p>\n “A classe implementando a interface deve usar uma assinatura de m\u00e9todo que seja compat\u00edvel com LSP (Liskov Substitution Principle). N\u00e3o fazer isso resultar\u00e1 em um erro fatal”<\/p><\/blockquote>\n Aqui est\u00e1 um exemplo de um erro de heran\u00e7a com uma interface<\/a>:<\/p>\n No PHP 7.4, o c\u00f3digo acima lan\u00e7aria o seguinte erro:<\/p>\n Uma fun\u00e7\u00e3o em uma child classe com uma assinatura incompat\u00edvel lan\u00e7aria um aviso. Veja o seguinte c\u00f3digo da RFC:<\/p>\n No PHP 7.4, o c\u00f3digo acima simplesmente lan\u00e7aria um aviso:<\/p>\n Agora, esta RFC<\/a> prop\u00f5e sempre atirar um erro fatal para assinaturas de m\u00e9todos incompat\u00edveis. Com o PHP 8, o c\u00f3digo que vimos anteriormente acima iria provocar o seguinte:<\/p>\n Em PHP, se um array come\u00e7a com um \u00edndice negativo ( No PHP 7.4, o resultado seria o seguinte:<\/p>\n Agora, este RFC<\/a> prop\u00f5e mudar as coisas para que o segundo \u00edndice seja No PHP 8, o c\u00f3digo acima resultaria na seguinte matriz:<\/p>\n Com o PHP 8, arrays come\u00e7ando com um \u00edndice negativo mudam seu comportamento. Leia mais sobre as incompatibilidades para tr\u00e1s na RFC<\/a>.<\/p>\n Union Types 2.0<\/a>\u00a0aceitam valores que podem ser de diferentes tipos. Atualmente, o PHP n\u00e3o oferece suporte a tipos de uni\u00e3o, exceto para a sintaxe Antes do PHP 8, os tipos de uni\u00e3o s\u00f3 podiam ser especificados em anota\u00e7\u00f5es phpdoc, como mostrado no exemplo a seguir da RFC:<\/p>\n Agora, a RFC do tipo 2.<\/a> 0 prop\u00f5e adicionar suporte para tipos de sindicatos em assinaturas de fun\u00e7\u00f5es, para que n\u00e3o confiemos mais na documenta\u00e7\u00e3o em linha, mas definamos os tipos de sindicatos com uma sintaxe Como explicado por Nikita Popov no RFC,<\/p>\n “Apoiar tipos de sindicatos no idioma nos permite mover mais informa\u00e7\u00f5es do tipo phpdoc para assinaturas de fun\u00e7\u00e3o, com as vantagens habituais que isso traz:<\/p>\n Os tipos de Uni\u00e3o suportam todos os tipos dispon\u00edveis, com algumas limita\u00e7\u00f5es:<\/p>\n Voc\u00ea pode ler mais sobre a Union Types V2<\/a> na RFC.<\/p>\n Ao passar um par\u00e2metro de tipo ilegal, fun\u00e7\u00f5es internas<\/a> e fun\u00e7\u00f5es definidas pelo usu\u00e1rio<\/a> se comportam de forma diferente.<\/p>\n Fun\u00e7\u00f5es definidas pelo usu\u00e1rio lan\u00e7am um Isto resultaria no seguinte aviso:<\/p>\n Se Esta situa\u00e7\u00e3o levaria a uma s\u00e9rie de problemas bem explicados na se\u00e7\u00e3o de quest\u00f5es do RFC<\/a>.<\/p>\n Para remover estas inconsist\u00eancias, esta RFC prop\u00f5e<\/a> fazer a an\u00e1lise interna dos par\u00e2metros APIs para sempre gerar um No PHP 8, o c\u00f3digo acima lan\u00e7a o seguinte erro:<\/p>\n Em PHP, Esta RFC<\/a> prop\u00f5e converter a declara\u00e7\u00e3o Veja os seguintes exemplos da RFC:<\/p>\n Um Weak Maps \u00e9 uma cole\u00e7\u00e3o de dados (objetos) nos quais as chaves s\u00e3o fracamente referenciadas, significando que elas n\u00e3o s\u00e3o impedidas de serem coletadas.<\/p>\n PHP 7.4 adicionou suporte a refer\u00eancias fracas<\/a> como uma forma de reter uma refer\u00eancia a um objeto que n\u00e3o impede que o objeto em si seja destru\u00eddo. Como apontado por Nikita Popov,<\/p>\n “Refer\u00eancias fracas em bruto s\u00e3o apenas de utilidade limitada por si mesmas e mapas fracos s\u00e3o muito mais comumente usados na pr\u00e1tica. N\u00e3o \u00e9 poss\u00edvel implementar um Weak Maps eficiente em cima de refer\u00eancias fracas em PHP porque a habilidade de registrar uma chamada de retorno de destrui\u00e7\u00e3o n\u00e3o \u00e9 fornecida”<\/p><\/blockquote>\n \u00c9 por isso que esta RFC<\/a> introduz uma classe Em processos de longa dura\u00e7\u00e3o, isto evitaria vazamentos de mem\u00f3ria e melhoraria o desempenho. Veja o seguinte exemplo da RFC:<\/p>\n Com o PHP 8, o c\u00f3digo acima produziria o seguinte resultado (veja o c\u00f3digo em a\u00e7\u00e3o aqui<\/a>):<\/p>\n Se voc\u00ea desajustar o objeto, a chave \u00e9 automaticamente removida do Weak Maps:<\/p>\n\n
\n
![\"Processo](\"https:\/\/kinsta.com\/wp-content\/uploads\/2020\/05\/php-execution-1.png\")
A extens\u00e3o OPcache<\/h3>\n
![\"Processo](\"https:\/\/kinsta.com\/wp-content\/uploads\/2020\/05\/php-execution-2.png\")
phpinfo()<\/code><\/a> a partir de um script em seu servidor ou verificando seu arquivo php.ini (veja as configura\u00e7\u00f5es de configura\u00e7\u00e3o do OPcache<\/a>).<\/p>\n![\"Zend](\"https:\/\/kinsta.com\/wp-content\/uploads\/2020\/05\/zend-opcache.jpg\")
Pr\u00e9-carga<\/h3>\n
JIT – O compilador Just in Time<\/h3>\n
JIT para aplicativos web em tempo real<\/h3>\n
![\"Contribui\u00e7\u00e3o](\"https:\/\/kinsta.com\/wp-content\/uploads\/2020\/05\/php-8-performance-diagram.png\")
\n
Melhorias e novas funcionalidades do PHP 8<\/h2>\n
Promo\u00e7\u00e3o de propriedade dos construtores<\/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>\nHeran\u00e7a<\/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>\nO que n\u00e3o \u00e9 permitido com as propriedades promovidas<\/h4>\n
Construtores abstratos<\/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>\nTipo Callable<\/h5>\n
class Test {\n \/\/ Error: Callable type not supported for properties.\n public function __construct(public callable $callback) {}\n}<\/code><\/pre>\nA palavra-chave var n\u00e3o \u00e9 permitida<\/h5>\n
var<\/code> (veja o seguinte exemplo do RFC):<\/p>\nclass Test {\n \/\/ Error: \"var\" keyword is not supported.\n public function __construct(var $prop) {}\n}<\/code><\/pre>\nSem duplica\u00e7\u00f5es permitidas<\/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>\nPar\u00e2metros Variadic n\u00e3o s\u00e3o permitidos<\/h5>\n
class Test {\n \/\/ Error: Variadic parameter.\n public function __construct(public string ...$strings) {}\n}<\/code><\/pre>\nLeituras adicionais<\/h4>\n
Valida\u00e7\u00e3o para m\u00e9todos de tra\u00e7os (trait\u00a0) abstratos<\/h3>\n
\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>\nAssinaturas incompat\u00edveis do m\u00e9todo<\/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 come\u00e7ando com um \u00edndice negativo<\/h3>\n
start_index < 0<\/code>), os seguintes \u00edndices come\u00e7ar\u00e3o a partir de 0 (mais sobre isso na documenta\u00e7\u00e3oarray_fill<\/code> <\/a>). Veja o exemplo a seguir:<\/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>, qualquer que seja o valor de 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> e para o tipo especial 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>:<\/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> n\u00e3o poderia ser parte de um sindicato, pois void<\/code> significa que uma fun\u00e7\u00e3o n\u00e3o retorna qualquer valor<\/a>.<\/li>\nnull<\/code> s\u00f3 \u00e9 suportado em tipos de uni\u00e3o, mas seu uso como um tipo aut\u00f4nomo n\u00e3o \u00e9 permitido.<\/li>\n?T<\/code>) tamb\u00e9m \u00e9 permitida, significando T|null<\/code>, mas n\u00e3o \u00e9 permitido incluir a nota\u00e7\u00e3o ?T<\/code> nos tipos de uni\u00e3o (?T1|T2<\/code> n\u00e3o \u00e9 permitido e devemos usar T1|T2|null<\/code> em seu lugar).<\/li>\nstrpos()<\/code>, strstr()<\/code>, substr()<\/code>, etc.) incluem false<\/code> entre os poss\u00edveis tipos de retorno, o pseudo-tipo false<\/code> tamb\u00e9m \u00e9 suportado.<\/li>\n<\/ul>\nErros consistentes do tipo fun\u00e7\u00f5es internas<\/h3>\n
TypeError<\/code>, mas fun\u00e7\u00f5es internas se comportam de v\u00e1rias maneiras, dependendo de v\u00e1rias condi\u00e7\u00f5es. De qualquer forma, o comportamento t\u00edpico \u00e9 lan\u00e7ar um aviso e retornar null<\/code>. Veja o seguinte exemplo no 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> estiver habilitado, ou se a informa\u00e7\u00e3o do argumento especificar tipos, o comportamento seria diferente. Em tais cen\u00e1rios, o erro de tipo \u00e9 detectado e resulta em um TypeError<\/code>.<\/p>\nThrowError<\/code> no caso de um descasamento do tipo de par\u00e2metro.<\/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>\nExpress\u00e3o throw Come<\/h3>\n
throw<\/code> \u00e9 uma declara\u00e7\u00e3o<\/a>, portanto n\u00e3o \u00e9 poss\u00edvel us\u00e1-la em lugares onde apenas uma express\u00e3o<\/a> \u00e9 permitida.<\/p>\nthrow<\/code> <\/a> em uma express\u00e3o para que ela possa ser usada em qualquer contexto onde as express\u00f5es s\u00e3o permitidas. Por exemplo, fun\u00e7\u00f5es de seta<\/a>, operador de coalesc\u00eancia nula<\/a>, operadores tern\u00e1rios e elvis<\/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
WeakMap<\/code> para criar objetos a serem usados como chaves fracas de mapas que podem ser destru\u00eddos e removidos do Weak Maps se n\u00e3o houver mais refer\u00eancias ao objeto chave.<\/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>\n