| Subject: | Mudanças no PHP6 serão polêmicas |
|---|
Para aqueles que estão desenvolvendo o projeto final em php, bom dar
um olhada...Att,
Giselle Marques
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.
More...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, mmuitas
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
contribuiram 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.
link: http://www.meiobit.com/destaque/mudancas_no_php6_serao_polemicas