PHP6 - O PRINCIPIO DA MUDANÇA

Um problema chamado mudança
O problema é simples de entender , mas a solução pode vir a dar dor de cabeça a muitos programadores ou freelancers em PHP.
Imaginem que possuem trabalhos realizados em PHP , cujos conteúdos estão publicados na web e que muitos dos clientes para que realizaram os trabalhos dependem deles para o seu modelo de negócio.
Agora imaginem que alguém responsável pelo "core" de desenvolvimento PHP, se lembrava de reestructurar a linguagem e muitas das funções e funcionalidades existentes até aquí deixam de estar acessíveis, tornando muitas aplicações e web sites totalmente obsoletos .
Parece brincadeira , mas não é ! Segundo consta, as pelas últimas noticias emanadas pela comunidade de desenvolvimento da linguagem, a nova versão PHP6 terá este enorme problema. A garantia de isso iria acontecer foi publicamente confirmada por Derick Rethans , um dos obreiros actuais da linguagem.
O problema apenas se verificará quando os responsáveis pelos manutenção dos sites online actualizarem os servidores para a nova versão PHP6.
Geralmente as empresas responsáveis pelo alojamento ou manutenções do site tinham a preocupação de manter as versões anteriores a correr de forma a manterem no activo antigas aplicações.
Com esta alteração de fundo muitas das aplicações simplesmente deixaram de funcionar; e apesar da versão 6 do PHP não ter sido lançada, o resultado da imcompatibilidade começou a ser notado, e foi tornado publico pelo equipa de desenvolvimento da versão PHP6.
Mas o que poderão fazer os criadores, empresas e freelancers para ultrapassar esta questão ?
Em primeiro lugar será necessário rever o tipo de contracto que tem com os seus clientes, mas será sempre melhor ter em conta que essa manutenção terá de ser gratuíta, pois ela não é imposta pelo cliente mas por uma exigênçia da tecnologia.
Outro ponto fulcral, abona o facto de que o cliente pagou por um serviço que na maioria dos contratos é vitalicio (salvo raras excepções), daí que esse produto, seja ele um site ou não no mínimo terá que possuir as funcionalidades que continha até a aqui.
O PHP6 permitir-lho-á, mas a aplicação necessitará de ser reprogramada de forma a substituir as "depracted functions" pelas novas funções e novas funcionalidades.
O problema resume-se fundamentalmente ao afacto de que a nova versão PHP6 será incompativel com as versões anteriores PHP4 e 5.
Mas o que será necessário alterar para que tudo o que funcionava até aquí continue a funcionar ?

Para melhor entender a solução é necessário estudar e perceber aquilo que irá ser alterado.
A noticia já havia sido antecipada no encontro realizado em Paris em Novembro de 2005 (dias 11 e 12), mas por inércia ou qualquer outro factor somente agora se está a dar a devida importância ao assunto. Mesmo na altura se dava conta que as alterações mencionadas seriam feitas de forma progressiva. Mas com o decorrer do tempo e à medida que essas alterações vão sendo implementadas, as questões e dúvidas vêm à tona e deixa muitos atónitos , nao percebendo bem aquilo que se está a passar. O certo é que esssas alterações de fundo ao "core" da linguagem vão mesmo ser implementadas.
Vou em seguida falar de forma o mais suscinta possível acerca das tão faladas mudanças e da forma como afectam os códigos escritos em PHP.

Mudanças fundamentais

UNICODE

O unicode não é uma mudança mas sim uma novidade no PHP, já na versão 6.
O Unicode associa um número a cada caracter independentemente do programa ou da plataforma ou da língua.
Desta forma as aplicações ganham uma maior flexibilidade e fiabiliadade.
Ofereçer a padronização Unicode permite às empresas (essencialmete no ramo dos servidores), reduzir custos, uma vez que o conjunto de caracteres legacy são desnecessários.
Além disse este recurso torna a linguagem mais poderosa, pois a a fusão com outros padrões permite tirar maior partido da linguagem; e por exemplo o XML tem a necessidade de codificação Unicode.

O Unicode é visto como uma nova funcionalidade, mas todas as restantes alterações não irão funcionar quando utilizadas em códigos a correr em versões anteriores, gerando erros na execução , impedindo que os serviços funcionem.
Fica assim possível escrever classes com acentuação. Este é uma exemplo, mas existe milhares de aplicações onde isto é mais vantajoso.

Alterações de fundo

Existem no entanto uma série de alterações que estão a deixar os programadores de cabelos em pé.
O site ofical do PHP deixa transparecer algumas das alterações já a decorrer.

Remoção completa das "register_globals"

As register_globals eram frequentemente usadas para o tratamento de formulários.
Em versões do PHP anteriores a 4.2.0, a diretiva register_globals tinha como valor padrão estar activada, o que, por questões de segurança, não acontece nas versões actuais.
Contudo por desconhecimento ou por descuido, esta constitui uma falha grave na segurança aos servidores que interpretam código PHP.
Actualmente os programadores experientes tem formas alteranativas de implementar esta funcionalidade mas, para quem a use ainda ou em aplicações a correr sob PHP6 deixará de estar assecível.

Remoção " magic_quotes_* "

Esta é uma alteração já esperada há muito tempo, uma vez que nem sequer é uma forma segura de programar e a maioria dos programadores nem sequer usa esta funcionalidade (?).

Aceder às funcionalidades activas e desactivas no Painel de control

Segudo foi tornado público, os programadores terão a possibilidade de ligar e desligar funcionalidades, sem intervenção do administrador do servidor.
Esta medida não é concerteza coerente, pois não estou a ver um administrador de serviços web, que não quer que utilizemos as contas de email ou de FTP , tenha um canal aberto que contaria as restrições impostas ... (?) , no mínimo estranha e discutivel esta medida.

Remover tudo aquilo considerado desactualizado até as versões 3 e 4

Aquí esta uma medida que no mínimo provoca a discordia. Com esta medida todos os scritpts, mais antigos serão obsoletos,uma vez que deixarão de funcionar, ou impondo obrigatóriamente a que o código seja reescrito ou actualizado.
Isto implica perca de tempo, pelo que em aplicações de pequeno porte o melhor será reescrever a aplicação na totalidade.
Em aplicações consideráveis ficará ao critério de cada um.


.... este artigo está incompleto
volte em breve