PHP 7.3 - O que está por vir e o que está para ir

Publicado em 06 de agosto de 2018 às 16:36

php 7.3

Quem trabalha na área de tecnologia da informação, sabe que essa área foi e é uma das áreas menos afetadas pela crise financeira no Brasil. Os desenvolvedores de software e gestores de TI têm encontrado menos problemas para recolocação no mercado quando comparado a outras áreas, apesar de sim, ter havido uma pequena retração.

Com sinais visíveis da retomada da economia, o mercado de TI se tornará ainda mais fértil para os candidatos e concorrido para as empresas. Mas, para que isso aconteça, é preciso que você DEV se mantenha sempre atualizado e busque ficar por dentro das novidades. Afinal, saber somente o básico já não é mais uma vantagem.

Por isso, hoje vamos falar sobre as atualizações envolvendo PHP. Sendo lançado oficialmente no final de 2015, o PHP 7 vem ganhando diversas atualizações – mas será que quando atualizamos a versão do PHP sabemos realmente a motivação dela?  A segurança? Bug fix? New Features? Performance?

Às vezes, atualizamos só por atualizar e isso é bom, mas é vago. No meio do caminho de uma versão para outra podemos ter novas funcionalidades, que facilitam nosso trabalho; elas podem trazer mais performance, como também, trazer descontinuações de funcionalidades que podem conduzir aos mesmos benefícios que falei a pouco ou ainda, levar a uma dor de cabeça ao migrar de uma versão antiga para outra mais nova.

Em resumo, se você não acompanha esse tipo de novidade, trarei algumas aqui.

De acordo com o planejado **Tarefas de Preparação do PHP 7.3, a versão será disponibilizada para o público em 13 de dezembro de 2018. Até chegar nessa data, muito do que vamos falar estará implementado para testarmos as mudanças.

Estas propostas surgiram através de RFC (Request for Comments), na qual um ou mais autores propoẽm uma mudança e outras pessoas argumentam a validade da mesma. Se for uma idéia válida, esta entrará em votação e se for aprovada a implementação vai para o release, sendo assim, não será descartada.

Descontinuação ao suporte de constantes "case-sensitive”

O que a RFC nos diz:

  • In PHP 7.3: Deprecate calling define () with third parameter true.
  • In PHP 7.3: Deprecate accessing a case-insensitive constant with a casing that differs from the declaration-site. The constants true, false and null are exempt from this.
  • In PHP 8.0: Remove the possibility of declaring case-insensitive constants.
  • In PHP 8.0: true, false and null are converted from special-cased constants into reserved keywords.

 

Redeclarar uma constante case-sensitive não é permitido:

define('FOO', 42);
var_dump(FOO); // int(42)
define('FOO', 24); // Notice: Constant FOO already defined
var_dump(FOO); // int(42)

 

Redeclarar uma constante case sensitive é permitido - WTF?

define('foo', 42, true);
var_dump(FOO); // int(42);
define('FOO', 24);
var_dump(FOO); // int(24)

 

A partir do PHP 7.3 tanto ao criar quanto acessar uma constante gera um Deprecation warning. A partir do php 8.0 constantes case-insensitives serão removidas completamente:

 

define('FOO', 42, true); // Deprecated: define(): Declaration of case-insensitive constants is deprecated
var_dump(FOO); // Ok!
var_dump(foo); // Deprecated: Case-insensitive constants are deprecated. The correct casing for this constant is "FOO"

 

Novas funções para lidar com arrays: array_key_first($array) e array_key_last($array)

Há como pegar esses valores atualmente, porém, é necessário o uso de funções auxiliares, algumas dela mexendo no ponteiro do array só para pegar a informação específica. Por exemplo, usando as funções reset(), end() and key().

 

// usage of an associative array
$array = ['a' => 1, 'b' => 2, 'c' => 3];

$firstKey = array_key_first($array);
$lastKey = array_key_last($array);

assert($firstKey === 'a');
assert($lastKey === 'c');


// usage of a numeric array
$array = [1 => 'a', 2 => 'b', 3 => 'c'];

$firstKey = array_key_first($array);
$lastKey = array_key_last($array);


assert($firstKey === 1);
assert($lastKey === 3);


// usage of an empty array
$array = [];

$firstKey = array_key_first($array);
$lastKey = array_key_last($array);

assert($firstKey === null);
assert($lastKey === null);

 

Sintaxe mais permissiva Heredoc/Nowdoc:

Como é hoje? É obrigado o marcador de fechamento da tag "EOT" não ter espaço ou tab e é obrigado também quebrar para a próxima linha após o marcador final "EOT"

class foo {
   public $bar = <<<EOT
bar
EOT;
}

 

A proposta dessa RFC é flexibilizar a tag de fechamento, que pode ser indentada e remover a obrigatoriedade de quebrar para a próxima linha após a tag de fechamento:

 

class foo {
   public $bar = <<<EOT
   bar
   EOT;
}

 

Se a tag de fechamento for indentada além do tamanho da última linha do corpo, um ParseError é emitido:

 

echo <<<END
 a
b
c
END;


// Parse error: Invalid body indentation level (expecting an indentation at least 5)

 

Obrigatoriedade da quebra linha removida, o código abaixo funcionará normalmente:

 

$values = [<<<END
a
b
c
END
, 'd e f'];

 

Permitir adição de uma vírgula no parâmetro final de uma chamada de função:

Em funções que usam a técnica "variadic functions", funções com parâmetros variáveis, é bem útil, por exemplo:

 

unset(
   $somethingIDontNeedAnymore,
   $anotherOneToKill,
   $letsMakeThisEasy,
);

 

Ou:

echo $twig->render(
   'index.html',
   compact(
       'title',
       'body',
       'comments',
   )
);



 

Permitir variáveis como referência no construtor list():

$array = [1, 2];

[$a, &$b] = $array;

 

Nova função is_countable():

 

Desde o PHP 7.2, um warning é gerado ao tentar usar a função count() em variáveis incontáveis. Logo, o código a seguir era usado para fugir do warning:

 

if (is_array($foo) || $foo instanceof Countable) {
   return count($foo);
}

 

Após a implantação da função is_countable(), que verifica se dada variável implementa a interface Countable, a validação ficaria mais sucinta:

 

if (is_countable($foo)) {
   // $foo is countable
}

 

Portanto DEV, fique atento às novidades envolvendo PHP e tantas outras linguagens que usamos no nosso dia a dia.