PHP 6.0 - Você está pronto?

Mal nos acostumamos com a idéia do PHP 4 estar obsoleto, já está sendo cultivada uma nova árvore. Uma boa notícia para os desenvolvedores e uma péssima para os administradores - pois dores de cabeça virão.

[ Hits: 16.576 ]

Por: Ragen Dazs em 23/11/2005 | Blog: http://www.orkut.com


Os ingredientes



Um ponto explorado no versão 5 do PHP foi a aplicação mais ampla da paradigma de orientação à objetos.

Houveram mudanças sutis quanto à compatibilidade da versão 4 para a 5, pois muitos recursos existentes na versão mais antiga ainda estão disponíveis na árvore da vez.

Muita gente deve ter se atentado que já há um bom tempo a equipe de desenvolvimento do PHP aconselhava que se modificassem os scripts PHP para o perfeito funcionamento sem a diretiva "register_globals = on". Talvez seja esse o maior impacto, pois quem não fez o Refactoring para atualizar seus códigos terá que fazê-los se não quiser deixá-lo obsoleto.

No PHP Internals, Rasmus Lerdof postou a lista das maiores modificações:
  1. Remover register_globals completamente;
  2. Remover o magic_quotes_*;
  3. Adicionar extensão de filtro de entrada, o qual irá incluir um mecanismo para os desenvolvedores de aplicações para muito facilmente torná-los Off, o que ativaria o acesso cru às arrays do GPC de volta no caso do site ter ativado como On por padrão;
  4. Incluir um opcode cache por padrão. Muito trabalho já foi feito no pecl/apc recentemente;
  5. Remover o safe_mode e focar no open_basedir;
  6. Remover algumas coisas que já foram marcadas como obsoletas desde o PHP 3/4;
  7. Transformar identificadores case-sensitive;
  8. Remover vários aliases para funções.

http://news.php.net/php.internals/17883 (Post original)

Uma nova vertente dos desenvolvedores do PHP quer a adoção do PDO (PHP Data Objects) como sendo parte nativa, ou seja, desde a versão 5.1 do PHP propõe-se que os desenvolvedores não mais utilizem o acesso direto à API de controle de base de dados - utilizando dessa extensão que atualmente vem sendo distribuída juntamente com o source original.

O que isso significa?

Meu objetivo não é dar a definição acadêmica para os mais puritanistas, mas sim a idéia principal. Como tal, sabe-se que o que era proposto a respeito da abstração de base de dados no PHP até então, se resumia à adição de camadas de controle como PEAR::DB ou o Creole. O PDO propõe uma interface de acesso de dados uniforme e não mais acesso à base de dados - o que de grosso modo seria o meio termo entre o Java Hybernate e DB::Pear até o presente momento, pois sua persistência segue o que foi proposto pelo Hybernate (embora ainda infinitamente mais primitivo) e ainda suporta recursos mais avançados como queries não buferizadas, statments preparados e etc.

Segundo os autores e desenvolvedores que participam do PHP Internals, o PDO está sendo adotado dentre vários fatores por ter um ganho de desempenho sobre a API nativa do PHP - não pela falta de qualidade da API nativa do PHP, mas sim pelo modelo proposto pelo PDO. E o que tudo indica é que em breve, será talvez um padrão de desenvolvimento.

Nesse meio tempo, muita gente já vinha esperando que fosse lançado para o PHP, um sistema de controle Unicode nativo. Um problema que se tornou mais evidente para programadores que trabalham com Ajax ou conhecem bem a tecnologia XMLHttpRequest e os problemas oriundos da acentuação e caracteres especiais em documentos XML.

Atualmente existe a extensão mbstring disponível - responsável principalmente por traduções UTF-8 -, mas que por padrão não vem habilitada na compilação do PHP e que por sua vez também possui várias limitações.

E para os administradores, tome-lhe fôlego, pois vocês ainda precisam aguardar o lançamento do Apache 2.1 - que promete novos recursos, como balanceamento proxy e novos recursos de integração com o Tomcat.

E isso ainda não para por aí, pois nesse período de mudanças, dor de cabeça pouca é besteira. O MySQL de árvore estável 4.1, em breve migrará para a 5, mas suas mudanças foram poucas e a mais drástica talvez foi a mudança do hash gerado pela função PASSWORD(), bases de dados antigas que utilizam hashs deverão ser migradas para o novo formato - felizmente um script já está incluso no release original.

Das funcionalidades novas para o PHP 5, estão os tão esperados controles de chaves primárias e estrangeiras (em cascata por exemplo), triggers e stored procedures. Novos recursos que muita gente não quer abrir mão.

No mundo da tecnologia, definitivamente o tempo não para.

[]'s
Allyson de Paula

   

Páginas do artigo
   1. Os ingredientes
Outros artigos deste autor

Referências ou ponteiros em PHP

O perigo no gerenciador de uploads do PHP

Adaptação das empresas de TI aos trabalhadores da era digital

XSS - Um exemplo de ataque

Projeto Icecream (parte 1)

Leitura recomendada

Configurando o DjbDNS

Mozilla Firefox com plugins para Flash e JAVA

Apache2 + PHP + PostgreSQL + phpPgAdmin

A Desinformação em Época da Tecnologia de Informação

IPv6 - Esclarecendo dúvidas

  
Comentários
[1] Comentário enviado por hlegius em 23/11/2005 - 08:32h

Realmente Ragen, o tempo não pára...
Muitos servidores ainda estão sobrando o PHP 4.x ... eu mesmo sofri um dia desses quando acabei uma aplicação para um cliente, e no servidor dele fui descobrir que rodava PHP 4. Conclusão: Muita coisa que fiz orientada a objeto, não rolou por simplesmente não existir no PHP 4. Não sei o que se passa, mas os admins de servidores precisam começar a jogar o PHP 5 nas máquinas, e nós usuários começar a dar preferência à servers que já disponibilizam aplicações mais recentes.

E parabéns pela notícia Ragen!

Abraços!

[2] Comentário enviado por juniorz em 23/11/2005 - 08:45h

Na última frase tem um erro:

"Das funcionalidades novas para o **MYSQL** 5, estão os tão esperados controles de chaves primárias e estrangeiras (em cascata por exemplo), triggers e stored procedures. Novos recursos que muita gente não quer abrir mão. "

Com relação ao PHP, vejo que a versão 4 atende a grande maioria das aplicações atualmente disponíveis com fonte aberto, e acho que esse é o principal motivo para os sysadmins não atualizarem o PHP para a versão 5, pois boa parte dos sistemas que hoje funcionam perfeitamente no PHP 4, apresentam prolemas no PHP 5.

[3] Comentário enviado por pablofilipi em 23/11/2005 - 08:51h

como fasso pra conseguir um apache que rode php 5

[4] Comentário enviado por fabio em 23/11/2005 - 09:30h

Estou em pânico, esse lance do register_globals vai me causar muita dor de cabeça e claro, a uma multidão de outros programadores. Digo isso por que tenho alguns sistemas e sites que foram programados na época do PHP 3 e claro, como todo bom prático, reutilizei blocos de código de muitos desses sistemas em meus sistemas atuais.

Agora imaginem só, quantos são os sistemas que ainda precisam de register_globals ativado pra funcionar!? Isso ainda vai dar bigode :)

[]'s,
Fábio

[5] Comentário enviado por jragomes em 23/11/2005 - 09:51h

Show de bola teu artigo. Muito esclarecedor.

A comunidade em torno do PHP é muito ativa, logo o desenvolvimento de novas coisas é constante.

Se olharmos o passado recente, veremos que o PHP fez grande evolução e é uma linguagem muito utilizada em aplicações pequenas e médias. Tem facilidades, já que é de fácil aprendizagem, tem o desenvolvimento rapidissímo e está sendo patrocinado por IBM (no websphere) e Oracle.

O PHP ainda vai dar muito o que falar, e no dia que pudermos "compilar" e gerar ".bins", o java e o .net terão encontrado um adversário a altura.

[6] Comentário enviado por jmsandy em 23/11/2005 - 10:52h


Ragen, parabéns pelo seu artigo.

Agora quanto a dúvida do amigo pablofilipi, se já tiver o apache configurado para outra versão do PHP sugiro que a remova. Depois na hora da compilação do PHP informe os parâmetros necessários sobre sua configuração que o módulo do php5 já será incorporado ao seu apache. Por exemplo:

# ./configure --with-apxs2-/usr/local/apache2/bin/apxs --wtih-mysql --with-gettext
# make
# make install

Sugiro que leia este artigo que poderá de esclarecer melhor:

http://www.vivaolinux.com.br/artigos/verArtigo.php?codigo=4018

O artigo foi bem elaborado pelo meu bom amigo jlojúnior.

Falow.

[7] Comentário enviado por lennon.jesus em 23/11/2005 - 12:56h

As áreas ligadas á Tecnologia da Informação são bastante perigosas... Temos que estar antenados o tempo todo. São atualizações simultâneas, conceitos novos, novas tecnologias... Tudo num verdadeiro ritmo de filme de ação!

O artigo é ótimo. Parabéns.

Abraços,
Lennon Jesus

[8] Comentário enviado por ragen em 23/11/2005 - 13:13h

Eu gostaria de fazer três ressalvas:

1 - Juniorz, obrigado pela correção, foi um ato falho me referir ao PHP, quando na verdade falava do MySQL.

Atualmente, das minhas experiências com migração de aplicações mostra que nem tudo que é proposto pelos desenvolvedores do PHP e MySQL funcionam como deveria.

A questão do hash gerado pela função PASSWORD('string') do MySQL 4, mudou com a árvore 4.1. Porém, foram adicionados scripts que fazem a conversão do tal hash antigo, pro novo modelo. Cabe a cada um adaptar o script fornecido para que a sua aplicação funcione corretamente.
Ou ainda, outra opção, foi adicionada a função OLD_PASSWORD(), que gera o hash ao modelo antigo.


2 - Para o pessoal que tá penando com a migração do PHP 4.x, para o 5.x

Atente-se à seguinte diretiva do php.ini:

; Enable compatibility mode with Zend Engine 1 (PHP 4.x)
zend.ze1_compatibility_mode = On

Você perde em desempenho, mas ganha em compatibilidade.


3 - Para o pessoal que vai se aventurar com PDO, atente-se!

O *****DRIVER***** do MySQL suportado pelo PDO, é da arvore 4.x.

Fiz testes e vi que se seu sistema (servidor web) for compilado com o PHP 4.x, instalado PHP com suporte ao PDO, e posteriormente instalar o MySQL 5.x, funciona.

O problema se dá quando você tenta compilar o PDO, usando as bibliotecas do MySQL 5!

[9] Comentário enviado por jeffestanislau em 23/11/2005 - 21:02h

Allyson,

Beleza de artigo!!

Realmente mudanças sempre causam dor de cabeça, é isso ainda tem muito caminho a ser percorrido.

Sobre o que o "hlegius" disse: Os admins deveriam atualizar o PHP em seus servidores.

Isso é uma coisa muito complexa, pois quem vai arriscar mexer numa estrutura que está servindo dezenas, centenas ou milhares de clientes em seus servidores apenas para ficar no top de linha da tecnologia e forçar seus clientes antigos a rever "por mais enxuto e versátil que seja o código" suas linhas para adaptar estruturas a este novo patamar do PHP.

Lembre-se que tem muito código "sujo", isto é, páginas com centenas de linhas misturadas com html e php no mesmo arquivo. Verificar, debugar, corrigir isso dá um tormento danado... sei por experiência pois passei alguns meses corrigindo códigos de terceiros de um projeto onde a empresa tinha investido muito tempo e dinheiro e os caras largaram tudo do jeito que estava... e olha que praticamente não havia comentários no código. Pense só no problema que uma migração mau pensada pode causar.

O que irá ou está acontecendo, é os grandes hosts inserirem novas máquinas específicas com php5 ou quando chegar o 6, para atender novos clientes que iniciaram seus projetos com a nova estrutura.

O mercado de programação é muito amplo, já a um bom tempo nas faculdades se diz que o Cobol é uma língua morta... mas há muitos sistemas que ainda rodam ele, e diga-se de passagem que estes profissionais são muito bem remunerados.

Não é sempre que o avanço da tecnologia agrada!!!

[]'s
Jefferson

[10] Comentário enviado por couver em 24/11/2005 - 14:58h

Muito bom seu Artigo.
Bem eu uso uma pequena "gambi" para fazer os registro globais trabalharem com o se estivese "register_globals = on", bem ao menos para mim funcionou... q é:

if (count($HTTP_POST_VARS) > 0) {foreach ($_POST as $name => $value) {${$name} = $value;}}
if (count($HTTP_GET_VARS) > 0) {foreach ($_GET as $name => $value) {${$name} = $value;}}

espero q ajude!!!

[]´s
Marcelo Siqueira

[11] Comentário enviado por removido em 24/11/2005 - 17:10h

Que venha a fera estarei aqui pronto para usa-lo.

[12] Comentário enviado por ursolouco em 10/12/2005 - 19:27h

Aperfeiçoar as diretrizes do PHP isso sempre vai acontecer. Hoje, em diversos servidores é possivel notar o register_globals 'on' e dificilmente vão ser alterados para 'off' pois não seria só um cliente afetados e sim muitas contas de usuários. O que se pode começar a fazer é, para novos servidores, a implementação do serviço com o register_globals of e passar ao usuários que não adianta chorar, fazer birra ou se jogar no chão que não vai ser alterado, pode-se, apenas, alterar a conta para outro servidor deixando assim mais um atrátivo para o usuário.

[13] Comentário enviado por presto em 19/10/2006 - 11:51h

Gostei da opinião do "ursolouco".

É uma saída interessante. =]

Vou estudar isso para o meu servidor!

Excelente artigo! :)

Gostei... =]

Mas tenho uma dúvida: ainda estou com PHP 4 no meu servidor... Migro para PHP 5 ou espero o 6?


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts