Ai galera eu estava lendo na net algumas noticias de PHP e encontrei essa aqui falando sobre

as mudanças no PHP6 e resolvi trazer aqui para que vocês possam dar uma lida o colocarem
sua opinião

*Este artigo foi idealizado e escrito por quatro colunistas do Meiobit em um trabalho conjunto.
Participaram Thiago Coelho, Bruno Alves, Cardoso e falcon_dark.

A versão atual do PHP é a 5.1.6 mas o núcleo de desenvolvimento da linguagem já trabalha na

versão 6. Da versão 4 para a 5 da plataforma ocorreram modificações profundas, tanto que
muitos scripts deixaram de funcionar. Isso ocasionou uma série de transtornos para
desenvolvedores, prestadores de serviço e usuários da linguagem. E, principalmente, um
atraso muito grande na adoção da versão 5. É comum, quando se contrata um servidor de
hospedagem, encontrar suporte ao PHP4 e ao PHP5 (este último normalmente em suporte
Beta) pois existe uma preocupação dos prestadores de serviço em suportar os scripts mais
antigos, que ainda são maioria.

A versão 6, que gera muitas discussões nas listas de desenvolvimento oficiais do PHP, pode
retirar muitas características da plataforma em uma operação de enxugamento para torná-la
mais prática de ser usada. O problema, novamente, é a compatibilidade legada. Com as
características que devem ser abandonadas muitos scripts escritos para as versões 4 e 5
podem, outra vez, parar de funcionar. Enquanto a equipe que desenvolve o PHP está
obviamente preocupada em tornar a linguagem mais profissional fica a dúvida se essas
modificações constantes podem afetar a credibilidade e a adoção do PHP como ferramenta de
desenvolvimento.

A notícia de que mudanças no PHP6 poderiam criar incompatibilidade com o legado das
versões 4 e 5 surgiu de um dos desenvolvedores da linguagem, Derick Rethans. Ele afirmou
publicamente que, entre outras coisas, o PHP6 dará suporte ao Unicode. Isso tornaria as
aplicações escritas em PHP mais internacionalizáveis, aumentando a flexibilidade do que pode
ser escrito com a plataforma. Entretanto, ao contrário dessa modificação, as outras propostas
retiram características que, quando usadas por scripts de outras versões, podem ocasionar em
erros de execução paralisando os serviços. Vamos discutir aqui algumas das modificações mais
profundas já propostas e seu possível impacto sobre as aplicações existentes escritas em PHP.
Entre o que está planejado para mudar no PHP6 aparece:

1-Remoção completa de register_globals Desde a versão 4 do PHP fala-se em abandonar

essa característica assim programadores mais experientes já produzem código sem usá-la.
Ainda que aplicativos escritos por desenvolvedores menos preocupados possam deixar de
rodar na versão 6 o impacto disso dever ser pequeno sobre os aplicativos profissionais.

2-Remoção de magic_quotes_* Boa parte dos programadores PHP sequer as usa e seu
abandono já era discutido há muito tempo. Deve ocasionar pouco impacto sobre a plataforma.

3-O PHP6 deve incluir um mecanismo para que os desenvolvedores desliguem opções
do ambiente que o administrador do site tenha deixado ligadas por padrão, e vice-
versa. Aqui vemos luzes vermelhas, pois os usuários não deveriam poder alterar opções do
sistema sem o uso de um mecanismo que limite o que pode ser alterado, nos moldes do
Apache. Não há indicação de que esse sistema vá existir o que pode gerar a situação incômoda
do desenvolvedor administrar mais o sistema do que o próprio administrador. É apenas uma
suspeita de nossa equipe que essa característica vá trazer problemas, mas a possibilidade está
em aberto.

4-Remoção do safe_mode e foco no uso de open_basedir O open_basedir é mais

restritivo que o safe_mode e por isso permite uma flexibilidade maior, entretanto em
servidores que armazenem diversos sites distintos (que é o caso mais comum na internet) o
compartilhamento de scripts pode tornar-se problemático. Ponto para a segurança, mas os
administradores de sistemas com PHP6 terão que suar um pouco mais a camisa.
5-Remoção de tudo que foi marcado como desatualizado desde o PHP 3/4 Muitos
scripts, principalmente os mais “antigos” vão parar de funcionar definitivamente, exigindo que
o código seja revisado e reescrito. Somando à isso o fato de querer aproveitar as novas
funcionalidades vai haver muita gente decidindo que a migração não vale a pena ou que é
melhor escrever a aplicação do zero do que ficar tapando buracos em código legado.

6-Tornar os identificadores sensíveis à caixa do texto Aqui haverá um problema para

desenvolvedores de Windows, que podem não estar acostumados com essa característica já
existente em diversas outras linguagens, como o C/C++, por exemplo. Desenvolvedores UNIX
não sentirão diferença pois nessa classe de sistema operacional a sensibilidade à caixa é
padrão. Nesse aspecto os hábitos antes alimentados pelo PHP podem exigir adaptação de parte
dos desenvolvedores. Além disso, scripts escritos com pouco cuidado podem parar de
funcionar.

7-Remoção de vários aliases de funções Scripts que fazem uso desses aliases não irão
funcionar na nova versão do PHP. É uma simplificação boa, já que é melhor ter apenas um
nome para cada coisa, e vai reduzir a complexidade do desenvolvimento. Mas outra vez os
desenvolvedores terão que optar entre permanecer com uma versão antiga da linguagem ou
trabalhar para modificar o código existente.

Essas são as principais modificações propostas para a versão 6 do PHP, que irão exigir cuidado
dos profissionais que decidam pelo upgrade em seus servidores. Entretanto não são as únicas,
muitas outras propostas e suas conseqüências podem ser observadas aqui. Certamente elas
devem atrasar a adoção da nova versão, como aconteceu com o PHP5. Na versão 5 muito foi
feito no sentido de tornar a linguagem orientada à objetos. Isso permite que os programadores
escrevam aplicações mais complexas e maduras, mas as incompatibilidades com o legado das
versões 3 e 4 do PHP foram um grande obstáculo para a adoção do PHP5. De tal sorte que o
PHP5 ainda não tornou-se o padrão para as aplicações PHP no mundo, havendo uma forte
presença do PHP4 no mercado.

O fato do cPanel demorar cerca de 6 meses para retirar do estágio Beta qualquer modificação
na plataforma PHP irá atrasar a migração de boa parte dos usuários. Muitos scripts livres e
gratuitos que são usados por uma parte grande do mercado, cujos administradores não são
programadores e usam código de terceiros, podem demorar para serem migrados para o PHP6
paralisando ainda mais o movimento de migração para a nova versão. As mudanças da versão
4 para a 5 obrigaram muitos desenvolvedores a reescrever seus scripts do zero e as quebras
de suporte legado propostas para a versão 6 irão deixar muitos programadores descontentes.

Ainda que os aplicativos desenvolvidos para o PHP4 que não tenham recebido adaptação para
a versão 5 possam ser reescritos ou adaptados diretamente para a versão 6 é impossível negar
que os programadores ficarão desconfiados. Começar os trabalhos para levar seus scripts para
a versão 6 valerá a pena? Haverá outra quebra de suporte legado em uma futura versão 7?
Essas perguntas agora encontram-se atrás de uma cortina de fumaça e devem levar algum
tempo para serem respondidas. Talvez o mercado só comece a migrar realmente para o PHP6
quando o grupo que desenvolve a linguagem comprometer-se a manter suporte para uma
nova versão. Podem se passar 2 ou 3 anos até que uma migração forte para a nova versão 6
seja verificada no mercado e até lá provavelmente poucos decidirão investir tempo e dinheiro
para adaptar scripts antigos para a versão 5, dando uma sobrevida inusitada ao PHP4.

Essas mudanças na plataforma PHP que causam falta de compatibilidade com aplicações
legadas são reflexos de um projeto pouco estruturado. A mudança de foco do PHP, desde seu
nascimento até hoje, também contribuíram para que mudanças tão profundas fossem levadas
à cabo. E é indiscutível que esse tipo de acontecimento abala o respeito que o mercado tem
por dada solução. Essas guinadas bruscas demandam retrabalho de profissionais cuja hora de
serviço não é das mais baratas. Produtos de empresas consolidadas, como Microsoft, Oracle, e
outras, raramente colocam seus clientes em posições tão desconfortáveis em tão curto espaço
de tempo. Esse panorama deixará muitos tomadores de decisão avessos ao PHP ainda que as
mudanças efetuadas sejam reconhecidamente necessárias e bem vindas pelos profissionais
técnicos.
Em uma análise mais profunda esse tipo de situação pode servir para o pessoal do Software
Livre repensar um pouco mais a forma como grandes projetos é manejada. Não são raros os
casos de projetos livres que obrigaram seus usuários a passarem pelo mesmo tipo de situação
que o PHP. O Drupal, por exemplo, CMS usado aqui no Meiobit é um exemplo de aplicação que,
de uma versão para outra, tornou todos os seus módulos incompatíveis e exigiu que
programadores e usuários fizessem malabarismos. Podemos citar também o Firefox, que na
versão 2 obrigou os criadores de extensões a adaptar suas criações à uma nova API. São
exemplos para o SL de que talvez seja necessário um comprometimento maior com certas
políticas tipicamente empresariais para manter seu mercado e sua comunidade.