Cancelamento do PHP 6 Antecipa Aceleração para o PHP 5.4

Autor Convidado: Este post foi escrito por Manuel Lemos, criador do site PHPClasses.org em 1999 e fundador da Icontem, empresa na qual atua desde 2001.

Em Março de 2010, os desenvolvedores do núcleo do PHP decidiram repensar o futuro desta linguagem.

Após cerca de 5 anos desenvolvendo aquilo que seria o PHP 6, o criador do PHP, Rasmus Lerdorf anunciou que a abordagem da principal novidade do PHP 6, suporte nativo a Unicode, teria de ser repensada.

Unicode é um padrão internacional para representar texto de caracteres de todas as linguas vivas usando uma só codificação. Isto significa que o Unicode permite escrever e misturar textos que incluiem caracteres de qualquer língua.

O principal recurso do PHP 6 ia ser o suporte nativo a Unicode. Isto significa que os desenvolvedores de PHP poderiam manipular textos de vários idiomas com as mesmas funções da linguagem que usam hoje, mas sem precisar de usar funções adicionais para combinar textos que usam conjuntos de caracteres de línguas diferentes.

O problema é que a abordagem pensada originalmente em 2005 para implementar nativamente o suporte do Unicode no PHP 6 estava demorando a ser implementada, já que o projeto era muito ambicioso. Além disso, existiam algumas dúvidas, se essa implementação não ia forçar uma perda de desempenho de aplicações de PHP, mesmo para as que não usassem esse recurso de suporte nativo a Unicode.

Por isso, o desenvolvimento do PHP 6, como versão separada do PHP 5, foi cancelado. Agora existe apenas um tronco de desenvolvimento. Esse tronco inclui outras novidades que estavam sendo pensadas para o PHP 6, além do suporte nativo a Unicode.

Existem dúvidas se a próxima versão do PHP se vai chamar PHP 5.4 ou PHP 6. O mais provável é que se chame PHP 5.4 uma vez que ainda não está claro se o suporte nativo a Unicode vai ser de fato incluído. Apesar desta dúvida, vamos considerar por agora que realmente vai ser PHP 5.4.

Integração da extensão de aceleração APC

Como consequência destas mudanças, uma das novidades que vai ser antecipada para o PHP 5.4 é a integração da extensão de aceleração APC.

Esta é uma de várias extensões que existem para PHP que permitem acelerar o carregamento de scripts usando um método de cache dos scripts.

Desde o PHP 4, lançado no ano 2000, a execução de scripts de PHP foi dividida em 2 partes: a compilação e a execução propriamente dita. A compilação cria em memória uma espécie de código compilado, que pode ser executado muito mais rapidamente do que quando o PHP ainda era uma linguagem totalmente interpretada, como ocorria até ao PHP 3.

As extensões de cache guardam em memória o tal código compilado. Isso permite que, depois de rodar uma vez, os scripts de PHP demoram bem menos para começar a executar.

Já existem extensões de cache de PHP de pouco tempo depois do PHP 4 ter sido lançado. Porém, estas nunca foram incluídas na distribuição principal do PHP por pressão da empresa Zend.

A Zend foi fundada por 2 dos principais desenvolvedores do núcleo do PHP. Como a Zend vende a sua própria extensão de cache do PHP, sempre se opuseram a inclusão de outra extensão de cache de código aberto na distribuição do PHP, já que certamente isso canibalizaria o seu produto comercial.

Porém, aceitaram a inclusão de uma extensão de cache no PHP 6. Isso daria tempo para a Zend criar outros produtos comerciais para se sustentarem.

Agora que o PHP 6 foi cancelado, o caminho ficou livre para antecipar a inclusão de uma extensão de cache de código aberto no PHP 5.4.

Existem várias extensões de cache para o PHP, porém é mais provável que incluam a extensão APC, pois é bem recebida pelos desenvolvedores do núcleo do PHP.

Outra extensão para o mesmo fim, o eAccelerator, é inclusive mais robusta e está sendo desenvolvida ativamente. Porém é distribuída com a licença GPL, que é incompatível com a licença do PHP. Por isso dificilmente poderá vir a ser incluída.

Apesar de tanto o APC como o eAccelerator funcionarem em servidores Linux e Windows, a Microsoft desenvolveu também a sua extensão de cache de código aberto para PHP, o WinCache. Assim, espera-se que o PHP funcione de forma mais otimizada em servidores Windows com IIS. Essa extensão pode ser obtida gratuitamente instalando o Microsoft Web Platform Installer.

Qual a importância disso para os desenvolvedores de PHP?

Em relação ao suporte nativo para a Unicode, pouco ou nada afeta os atuais projetos de PHP. Era um recurso que poderia facilitar um pouco o desenvolvimento de sites internacionais, mas realmente não é necessário.

Existem inúmeros sites internacionais escritos em PHP que usam Unicode, como Wikipedia, Facebook, Yahoo, só para citar alguns dos mais conhecidos. Mas realmente eles não precisam do suporte nativo a Unicode. Esses certamente usam outras extensões de PHP existentes como mbstring ou intl.

Quem desenvolve sites apenas em um idioma, nem precisa sequer pensar no assunto. Mesmo sites que misturam Inglês, Português, ou vários outros idiomas Europeus, podem continuar a usar a codificação ISO-Latin-1 (ISO-8859-1) como sempre, sem qualquer preocupação.

Quem realmente tinha mais interesse nesse suporte nativo a Unicode seriam empresa de sites que misturam texto que podem incluir línguas de países asiáticos ou do Leste Europeu.

Em relação à extensão de cache, sites que usam servidores dedicados ou servidores virtuais privados (VPS – às vezes associados à computação em nuvem), com certeza já estão usando extensões de cache, já que elas podem ser instaladas sem a necessidade de solicitação da empresa de hospedagem.

Se você tem sites de PHP em servidores dedicados ou servidores virtuais privados, mas não está usando uma extensão de cache, não pense duas vezes. Instale qualquer uma das outras extensões de cache, e comece já a se beneficiar da possibilidade de rodar PHP mais rápido, consumindo menos recursos do seu servidor.

Quem realmente pode se beneficiar mais da inclusão da extensão de cache na distribuição principal do PHP, são os sites que estão hospedados em servidores partilhados, que normalmente são os que oferecem hospedagem por preços mais em conta.

Existem algumas empresas de hospedagem que já instalaram extensões de cache nos servidores partilhados onde estão os sites dos seus clientes. Porém, uma grande parte dessas empresas não faz isso. Talvez seja por desconhecimento dessas extensões ou por incerteza em relação à sua estabilidade.

Com a inclusão do APC no PHP 5.4, muitas empresas de hospegam partilhada vão passar a ativar essa extensão de cache nos seus servidores, uma vez declarado o suporte oficial à inclusão do APC na distribuição de PHP, essas empresas vão se sentir mais confiantes para instalar o PHP com essa extensão.

No entanto, a extensão APC virá incluida na distribuição principal do PHP, mas vem desativada na configuração do PHP. Os administradores de sistemas das empresas de hospedagem precisarão ativar a extensão manualmente nos servidores partilhados que rodam os sites dos seus clientes.

Onde obter mais informações?

Estes e outros assuntos foram debatidos no podcast Lately in PHP do site PHPClasses.org. No episódio mais recente do podcast foram comentados estes assuntos, assim como outros também de grande interesse como o suporte para desenvolvimento de aplicativos nativos para celulares Android escritos em PHP. Aproveite agora para escutar o podcast ou ler a transcrição das discussões que aparecem no fim dos artigos.

0 responses to “Cancelamento do PHP 6 Antecipa Aceleração para o PHP 5.4

  1. Entendo a forma como a coisa toda aconteceu, e acho até que a solução dada foi interessante porque atendeu bem ao desejo da comunidade. Mas acho interessante comparar a situação com outras vividas dentro do mundo “open source”, por outras linguagens de peso como Perl, Python e Ruby.

    A briga da comunidade Perl nos últimos 10 anos tem sido com o Perl 6. A linguagem até hoje não tem uma especificação pronta e foi perdendo espaço aos poucos, em parte porque os concorrentes foram melhorando (Perl tinha uma vantagem imensa em ter sido a primeira a ganhar grande aceitação), mas em grande parte porque a redução no ritmo de desenvolvimento foi deixando as desvantagens da linguagem cada vez mais evidentes.

    Python teve também um momento de “vácuo” nos anos 90, durante a versão 1.5.2, por razões diferentes (falta de tempo e confusões de copyright). Mas a partir da 2.0 o processo se acelerou, e mesmo a versão que nunca iria sair (o famoso Python 3K, que virou 3.0) acabou saindo e está sendo adotados aos poucos. A forma como a linguagem lidou com temas complicados, como a própria migração para uma implementação 100% unicode-aware, chama a atenção.

    Ruby está passando pelo mesmo processo agora. A versão 1.9 está saindo e a 2.0, que vem, tem a missão (e o risco) de ser o ponto de maturação da linguagem. O forte crescimento da linguagem de uns quatro anos para cá aumenta o peso dessa missão. Resta saber se o caminho seguido será mais “Python-like” do que “Perl-like”, não no sentido das features da linguagem, mas no sentido em que se pretende evoluir de forma consistente ou “reescrever tudo do zero”.

    Pelo que podemos ver, PHP acabou seguindo um caminho mais parecido com o do Perl. A diferença é que em vez de ficar 10 anos no limbo, os desenvolvedores resolveram por um fim no dilema e apostar na versão 5, que é a que todo mundo efetivamente usa. É bom, porque garante estabilidade, mas ainda fica a dúvida se um dia eles irão conseguir dar o salto radical que Python já deu (da 2.0 para a 3.0) e que Ruby está se preparando para dar.

  2. Você acha que o Python 3k vai pegar? Eu não conheço muito a comunidade, mas pelo que vejo, ainda está bem longe de ser mainstream. O que eu acho interessante é que a comunidade Ruby, segue se desenvolvendo de maneira iterativa e buscando manter a maior compatibilidade possível. Será que o PHP 5.4 não abre caminho para um processo de desenvolvimento mais iterativo e retrocompatível?

  3. Acho que o Python 3K pega sim, com um pouco mais de tempo. As diferenças na prática tem se mostrado menores do que inicialmente era temido, em parte porque a migração não é obrigatória, o que está dando tempo para que códigos mais novos usem o Python 3K, ou pelo menos se preparem para uma migração futura. A forma como algumas funcionalidades estão sendo deprecadas e o backport seletivo de outras tem ajudado no processo.

  4. Ah, e antes que eu me esqueça, sua segunda observação é basicamente a mesma que a minha: o recuo para o PHP 5.4 é um passo correto, só não sei se está sendo tomado na hora certa, e se a comunidade conseguirá manter o passo depois do recuo. Mas é melhor do que ficar dando cabeçada (como a turma do Perl faz até hoje).

Deixe uma resposta para dttg Cancelar resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *