PHP 6, a versão amaldiçoada?
Resumo
O primeiro presente que dei ao meu namorado foi o livro “Programação com PHP 5.3” de Carlos Serrão e Joaquim Marques, corria o ano de 2009. Lembro-me de folhear o livro e o fechar rapidamente por medo da malfadada matemática. Finalmente ultrapassei esse preconceito e numa aula recente de lab 4, fiquei interessada na inexistência da versão 6 do PHP. Algo que mais tarde apelidei de “a maldição da versão 6”. O tema ideal para uma entusiasta de policiais do Perry Mason com uma costela supersticiosa.
As várias versões do PHP
Como qualquer história de suspense que se preze, temos que fazer um enquadramento ao início da nossa personagem principal, imagino um bonito elefante saltitante que nasceu em 1994 pelas mãos de Rasmus Lerdorf. Depois foi lançado em Junho de 95. Inicialmente era uma abreviação de “Personal Home Page”, até que foi renomeado o acrónimo para “PHP: Hypertext Preprocessor”. Em 1997 entrou no domínio público e um ano mais tarde dois programadores Andi Gutmans e Zeev Suraski, carinhosamente trato-os por pais adotivos do PHP, reescreveram a versão original e lançaram PHP3 que já possui ferramentas mais avançadas. PHP4 foi lançado em 2000, o qual incorporou o Zend Engine. Em 2004, PHP 5 foi lançado, incluindo um Zend Engine II. Sub-versões de PHP5 foram lançadas anos mais tarde. Durante 2014 e 2015, PHP versão 7 foi lançado. Em 26 de Novembro de 2020, chegou a versão 8 do PHP.
Medir a pulsação
A morte já foi anunciada diversas vezes, mas este elefante mais parece um gato com sete vidas. Lerdorf diz frequentemente em conferências, sim porque é um pai ainda presente, que nunca esperava que o PHP aguentasse mais do que 6 meses. Durante anos e anos pensou que esse fosse sempre o seu novo prazo de validade, antes de ser ultrapassado por algo melhor. Igualmente revela que não se acha um bom programador, por isso prefere criar os projetos e dar abertura a outros que o possam impulsionar.
É impressionante, cerca de quase quatro em cada cinco sites usam PHP, ou seja, 79.1%, muito graças ao facto de estar no core code do wordpress. É uma das linguagens mais usadas, corre no lado do servidor. É open source, por isso tem uma grande e fervorosa comunidade que contribui o seu futuro. Parece que está “vivinho da silva”, rápido e melhor que nunca.
Onde afinal paira a versão 6? O que lhe aconteceu?
Pode parecer que houve um erro, que a comunidade não aprendeu a contar de forma linear as versões. Mas não foi de todo o caso.
A versão 6 era muito promissora. Em meados de 2005, um grupo pequeno de pessoas começou-se a reunir para organizar essa versão. Foi um grande projeto logo desde o seu início, já que a premissa era acrescentar código Unicode nativo para o PHP.
O Unicode cobre quase todos os sistemas de escritas em uso atualmente. É então um standard usado para representar uma panóplia de caracteres e símbolos. A cada caractere é associado um número hexadecimal que o identifica (code point). Por exemplo, o número 65 é definido para representar um A maiúsculo.
Por muitos anos o sistema ASCII era adequado, mas tinha apenas um limite de 128 caracteres. Basta pensar um pouco em todos os emojis, tudo o que usamos para comunicar com os outros e percebemos que este número é, verdadeiramente, insuficiente. O sistema Unicode pode permitir mais de 1 milhão de code points. Mas a grande desvantagem é que ocupa tecnicamente mais espaço que o sistema ASCII. Com a globalização da comunicação, já tinha cada parte do mundo se adaptado a um sistema distinto. Tal como nós temos uma bitola ferroviária, ou seja, uma distância entre carris diferente à nossa vizinha Espanha. Imensas outras singularidades vemos espalhadas pelo mundo. Foi com o princípio de unificação que o Unicode foi criado em 1991, pela união de forças da Internacional Organization for Standardization e Unicode Consortium.
Parece que é uma boa premissa. Afinal havia com regularidade problemas de codificação. Já ouviram falar em Mojibake? Conhecem este simbolo?
Etimologia da palavra: Mojibake significa “transformação de caractere” em japonês. Moji = caractere + bake = transformação.
Muito frequentemente tem a ver um sistema de escrita distinto. É o resultado da substituição de símbolos por outros que estão completamente não relacionados, tanto pode ser o “símbolo do losango com um ponto de interrogação dentro”, como ser interpretado algo como sendo completamente diferente. É importante indicar que o processo de dados devido à falta de um determinado glifo numa fonte, ou mesmo devido à falta de fontes, é um assunto diferente e não deve ser confundido com Mokibake.
Graças à falta de implementação de Unicode em PHP, havia problemas frequentes. Por vezes, isso implicava corrigir manualmente os problemas de codificação para que nomes estivessem bem armazenados na base de dados, por exemplo.
A premissa era que PHP6 iria ter suporte Unicode em todo o lado; no engine, nas extensões, na API. Nativo e completo; sem truques, sem bibliotecas externas. Inglês é só outra linguagem e não a linguagem principal. Em 2006 parecia que o processo estava a ir bastante bem. Mas, uma decisão tomada logo no início do processo parece que colocou tudo em causa: o uso do UTF-16, que é composto por 2 bytes, ou seja, 16 bits. De acordo com o fundador Lerdorf, esta decisão foi feita para facilitar a compatibilidade com a biblioteca International Components for Unicode (ICU). Este é um projeto open source de C/C++ e Java para suporte ao Unicode. A ICU fornece serviços de manipulação de texto como: limite de caracteres, palavras e linhas. Até fusos horários, formatos de data e horas, etc…
A ideia da escolha de UTF-16 no início do projeto, foi até bastante ponderada. A lógica é iria haver a entrada e a saída da ICU para fazer várias operações Unicode, muito mais vezes do que iriamos fazer coisas externas como My SQL, por exemplo. Já que nós geralmente só lemos ou escrevemos uma string de uma fonte externa uma só vez, mas podemos usar múltiplas operações Unicode na mesma string.
Houve uma boa evolução, mas o processo de implementação do suporte Unicode arrastou-se por demasiado tempo. Em 2006 estava em 4.5% e passou para cerca de 70% em 2011 a conversão em PHP6.
O que correu mal?
No início dos trabalhos no PHP6, UTF-8 não estava suportado largamente, mas a indústria foi-se adaptando à sua flexibilidade. Já que é compatível com ASCII, tem mais do que 128 code points, vai de 1 a 4 bytes (graças a um sistema engenhoso para divisão de caracteres, neste caso o famoso “poop” emoji irá ser considerado na mesma mesmo precisando de mais do que 1 byte. Já que conseguimos “sinalizar” que vamos precisar de 4.
A indústria começou toda a adaptar-se às vantagens do UTF-8. Isso fez com que os problemas de compatibilidade que o PHP estava a tentar resolver deixassem de ser tão relevantes.
Outro dos fatores que pesou foi o facto das pessoas em open source só trabalharem no que estão interessadas, e além disso, eram relativamente poucas as pessoas que compreendiam o problema da conversão.
Se formos a ver usando utf-16 precisamos de usar sempre dois bytes, mesmo para algo como a letra A. Isso resulta em imenso “espaço” ocupado, cheio de nada. Isso afeta negativamente a performance do PHP, o que ainda acentua mais o efeito bola de neve.
Em 2009/2010 ficou cada vez mais aparente que o PHP6 nunca iria verdadeiramente ser lançado. Um dos pontos chave que mostrou uma posição foi em Março de 2010, o fundador do PHP ter confirmado, após alguma insistência de que o PHP6 ficará à parte, num ramo distinto. E tudo o que conseguir ser aproveitado pode ir para 5.3 lançamento e por aí adiante. Já que teria que se repensar a raiz do sistema Unicode escolhido, sem prazos e com mais alegria.
A partir daí, sem fim à vista… começou a ideia sobre que nome é que se iria chamar a próxima versão. Houve depois uma votação, em que a maioria escolheu que: já que iria haver uma reformulação assim tão grande no core e que não tinha a ver com o que estava previsto. Além do mais algumas coisas que eram da versão 6 foram sido acrescentadas à versão 5.x. Por isso, mesmo que alguns livros já tenham sido escritos, e também comprados. Não fazia sentido para a maioria da comunidade que votou, o PHP ser o 6, e ficou o próximo grande salto ficou sendo a versão 7.
Em suma
Dois dos pontos mais significativos para o desfecho do PHP6 foram:
· Escolha do UTF-16, em vez do UTF-8, essa decisão foi tomada numa altura em que ainda não tinha havido uma mudança drástica na estandardização da web para UTF-8.
· A falta de entusiasmo no envolvimento da comunidade, custo vs. benefício, complexidade da tarefa em mãos, quebra de performance e sem horizonte à vista.
