Renan de Lima

Navegando - e procurando coisas novas sobre PHP - achei um post interessante no blog PHP 10.0. É um FAQ sobre como vai funcionar namespaces no PHP 6. Tudo bem, não é novidade que o PHP terá namespace, mas o legal é assistir como ele está sendo construído. Achei o texto interessante e resolvi traduzí-lo.

Para acessar o texto original clique aqui. Veja também outro post sobre namespace e o design de como poderá ser o namespace em PHP 6.

Por que é necessário namespaces em PHP?
Porque nomes grandes como PEAR_Form_Loader_Validate_Table_Element_Validator_Exception são cansativos.

Qual é o principal objetivo do namespace?
Resolver o problema acima citado.

O que significa “namespace X::Y::Z”?
Todas as classes e funções são prefixadas com X::Y::Z

O que significa “import X::Y::Z as Foo”?
Um apelido para um namespace. Toda vez que uma classe ou função com o prefixo Foo for chamado, ele será traduzido para X::Y::Z.

O que significa “import X::Y::Z”?
Significa “import X::Y::Z as Z”, como no item anterior.

O que significa “import Foo”?
Nada.

Qual é o escopo do namespace e import?
Arquivo atual.

Um mesmo namespace pode ser utilizado em vários arquivos?
Sim.

Existe relação entre os namespaces X::Y::Z e X::Y?
Só na cabeça do programador.

Como faço para importar todas as classes de um namespace X::Y::Z para o escopo global?
Não é possível, isso nos traria o problema global da poluição espacial.
Entretanto você pode importar X::Y::Z e então prefixar sua classe com Z::.

Isso não faz com que haja nomes grandes?
Não maiores que três elementos: Namespace::Classe::Elemento.

Por que isso não é implementado como em <coloque sua linguagem favorita aqui>?
Porque PHP não é <coloque sua linguagem favorita aqui>.

Quando se fala de qualidade em Tecnologia da Informação, logo se pensa em CMM, MPS ou algo do tipo. Esses padrões são, em geral, gerais. De outra maneira e sem trocadilhos baratos os guias/padrões para a qualidade de software tratam de cuidar do nível gerencial. Tratam a qualidade de código como resultado de uma boa gerência.

Isso é errado? Se observamos da ótica “código bom é o código que funciona” (…) isso é certo!

Sugiro observamos a qualidade de software de maneira micro, pelas atividades. Para isso precisamos antes definir o que é qualidade de atividade de programação.

Aponto abaixo os itens básicos e necessários para a boa execução de atividade de programação, originárias das minhas experiências como programador. Estou deixando de lado itens como padrão de código, arquitetura, modularização dos componentes de software e sagacidade do programador. Se você teve outras experiências diferentes e queira colaborar ou questionar, sinta-se a vontade. Os itens básicos e necessários para a boa execução de uma tarefa são:

• Documentação: Clareza na definição do que deve ser feito e atalhos para os recursos/informações necessários para a execução da tarefa.
• Prazo: Compatível com o parecer técnico e sano do programador.

Nessa visão qualidade de atividade de programação é “código que funciona e no prazo!”. Ou seja, se os itens necessários não forem cumpridos, não consigo executar uma atividade de programação com qualidade.

Mas como faço pra saber se executei uma tarefa com qualidade? Faço a análise com quatro perguntinhas básicas. Se atente às palavras “inicialmente”, “realmente” e “fácil”, não as ignore. As perguntas são:

• Eu realmente terminei a tarefa?
• O que eu fiz é exatamente o que eu entendi que deveria ser feito inicialmente?
• Os recursos/informações que precisei foram de fácil acesso?
• Realizei a tarefa no prazo inicialmente determinado?

Não existe resposta certa para as questões. Por exemplo, um “não” como resposta para a segunda pergunta deve nos instigar a entender o que ocasionou a falha no entendimento do objetivo da tarefa. E como Caetano já dizia a culpa para os “nãos” respondidos pode ser minha, ou não.

Não dê pipoca aos programadores!

Dê documentação e prazo!

Há muito tempo fiquei devendo a publicação de uma biblioteca que exibe o rastro de uma execução de um script PHP. Fiz uma biblioteca que manipula um rastro e faz algumas coisa a mais que a chamada de um var_dump() com o parâmetro debug_backtrace().

O que essa biblioteca faz? De acordo com a documentação da classe principal: “Manipula e fornece acesso aos dados de uma determinada pilha de execução. Por meio de métodos é possível caminhar entre os níveis e capturar informações respectivas a cada um deles.”

E o que eu programador ganho com isso? Essa biblioteca tem me ajudado muito na correção de erros. Quem não utiliza debug para programar em PHP vai gostar bastante. Quem utiliza também, pois ele não serve apenas para exibir um erro durante a fase de construção de um projeto, ele pode ser utilizado no log ou envio de e-mail para facilitar a detecção e correção de erros. Conforme exemplo exibido o trace exibe parte do código (configurável) e destaca a linha em que ocorre mudança de nível no rastro.

Como utilizar?

Primeiro é necessário carregar as classes:

include_once “backtrace/BackTrace.php”;
include_once “backtrace/BackTraceExplain.php”;

Depois utilizar onde deseja exibir o rastro:

$oTrace = new BackTrace();
echo $oTrace->explain();

A classe BackTrace tem um monte de metódos interessantes, mas o explain é o mais legal. Pra quem for curioso dê uma olhadinha na classe BackTraceExplain, que é a classe utilizada por esse método.

Outra possibilidade de utilização dessa biblioteca é em uma função que faz dump de qualquer coisa. Enfim, as possibilidade são diversas. Abaixo o link para download da biblioteca.

BackTrace 0.0.1

A imagem ao lado ilustra um exemplo do resultado da utilização integrada com outra biblioteca de manipulação de erro em um site com o Zend Framework. Perceba que o exemplo é a exibição de um notice.

Qualquer bug, sugestão ou reclamação, por favor, serão bem-vindos neste tópico.