Note:for English readers hitting this post: written in Portuguese, about a non-existing feature (variable class type cast) of php5, bith 5 and 6, and one good-argument on how it would improve programming efficiency through ide improved functionality.

UPDATE: check this post for a “solution” to class cast in PHP.

Escrevo este post como verdadeiro fã do PHP. Mas não como aquele que se limita a louvar as suas potencialidades, antes como aquele que gostava que o PHP evoluísse e se tornasse ainda mais poderoso.

O PHP não implementa um verdadeiro sistema de type cast o que não impõe qualquer limitação ao desenho das aplicações, até porque: 1) na sua natureza o PHP é verdadeiramente dynamic e weak typed; 2) implementa as conversões suficientes para que o programador se possa exprimir sinteticamente nas operações frequentes; 3) tudo o resto pode ser obtido através de um sistema de reflexão completo e performante.

Contudo, o facto de não possuir uma sintaxe que permita explicitar o tipo esperado de uma variável tem um impacto extremamente negativo sobre a produtividade do desenvolvimento.

Exemplo

Se criarmos uma instância de uma determinada classe o Eclipse sabe determinar os membros acessíveis. Basta fazer Ctrl+Espaço e zás obtemos a lista das propriedades e métodos e podemos logo ali ler a info retirada dos doc blocks. E se escolhermos um método ele dá-nos a lista dos argumentos, os tipos e mais um par de botas.

O mesmo se passa no Eclipse se obtivermos uma variável como retorno de uma função/método que tenha documentado o tipo no @return do doc-block. É o que se pode esperar de um first-class IDE, certo?

O problema é quando a classe da variável em questão só pode ser determinada em run-time. Nesse caso o IDE não faz a mínima ideia do que se trata. Em muitos casos não há volta a dar à questão, nomeadamente quando o caso está a tirar proveito do dynamic binding, o que é normal.

Mas no caso seguinte, concretamente, estou a usar um método que me pode retornar uma instância de uma qualquer classe da framework. Na realidade o método retorna especificamente o tipo OliveResource, mas esta é apenas uma interface de identificação que não contém quaisquer membros.

O retorno pode ser, por exemplo, uma instância de um controlador, um componente, uma conexão à base de dados, uma tabela, … enfim, quase tudo! Mas em praticamente todos os casos eu sei perfeitamente que a instância deverá ser de um determinado tipo, ou pelo menos é conhecida uma qualquer super classe do objecto

Mas o IDE não sabe e eu não tenho maneira de lhe passar essa informação. Porquê? Porque não é possível fazer o cast para user object, class, interface, apenas para primitivas e stdClass.

Sugestão

A minha sugestão seria que, no mínimo, implementassem uma syntaxe para explicitar o type. Mesmo que a designação fosse ignorada logo no momento do parse. Assim o IDE saberia determinar os membros acessíveis e dar aquela ajudinha preciosa.

No exemplo referido em cima se fosse possível escrever algo como…

… e mesmo que OliveModelDefault designasse uma classe abstracta, o IDE já me dava todos os métodos e propriedades públicos (documentados!!!) dessa classe e eu só teria que recorrer à documentação para tirar dúvidas quanto aos membros das sub-classes.

Claro que seria ideal que numa segunda fase implementassem o check de runtime para avaliar se o objecto é compatível com a classe/interface designada e lançar uma excepção caso não seja.

Infelizmente esta funcionalidade não está prevista para o PHP6. Tal como já comentei aqui, as mentes brilhantes por detrás do projecto, terão considerado que isto não é “the php way”.