Futuro do PHP [sintaxe]

[Kazzkiq 2]

Olá pessoal!

 

Bom, como todos sabem a linguagem PHP evoluiu muito de alguns anos para cá. São tantas novidades que agora fazem parte nativamente desta linguagem incrível, que se for ficar falando nelas desde a versão 4.x até a atual (5.4.x) iriamos escrever um livro de umas 1000 páginas.

 

Mas com essa evolução e amadurecimento da linguagem (que inicialmente se focava em coisas simples, como templates e páginas pessoais), também vem alguns requisitos que uma linguagem grande necessita para se organizar (a nível de sintaxe). E é sobre isso que eu gostaria de conversar com a comunidade aqui do fórum.

 

 

Funções e seus nomes-padrões:

Atualmente o PHP tem uma porrada de funções nativas, cada uma destinada a um uso, e para tentar "organizar" elas de forma que quem for usar a função saiba mais ou menos do que se trata, os desenvolvedores responsáveis pela linguagem criaram letras padrão para as funcões como por exemplo o srt (srtrreplace, srtrpos, strstr, etc). Mas o problema aqui é que estes nomes não são exatamente padronizados, por exemplo existe a função strripos relacionada a strings, mas também existe a str_replace, que já usa um underline ("_") para separar o nome. E este é só um exemplo.

 

Bom, eu não sei se isto foi intencional, ou foi descuido por parte dos desenvolvedores, mas o fato é que o uso aleatório de nomes em funções não ajuda na padronização e melhora da linguagem como um todo, sem contar que pra quem está começando a aprender PHP pode até ser um obstáculo a mais para entender o motivo dessas diferenças nos nomes.

 

 

Funções OO:

Como eu disse no inicio, com o avanço da linguagem, vieram os pacotes nativos para se trabalhar com OO, mas por que não reestruturar a sintaxe de modo que todas as funções se comportem de tal modo, mais uma vez ajudando na padronização da linguagem?

 

Por exemplo:

 

$string = "Eu sou o rei do gado.";
$string = explode(" ",$string);

 

 

se tornaria:

 

$string = "Eu sou o rei do gado.";
$string->explode(" ");

 

Não seria mais fácil o entendimento?

 

Um exemplo maiorzinho:

 

$string = "Eu sou o rei do gado.";

$string = explode(" ",$string);
$string = array_reverse($string);
$string = implode(" ",$string);

#tambem poderia ser: $string = implode(" ", array_reverse(explode(" ",$string)));

 

 

se tornaria:

 

$string = "Eu sou o rei do gado.";
$string->explode(" ")->array_reverse()->implode(" ");

 

 

Bem mais conciso, não?

 

Esses são só dois tópicos que eu mostro aqui que ao meu ver precisam de certa melhoria, existem muitos outros, muito mais profundos também, mas isto já é um começo para dar pitaco sobre o que o futuro do PHP nos reserva. :yes:

__

 

 

Bom, já me blindando contra eventuais ataques de engessos arcaicos, gostaria de deixar claro que meu objetivo não é reclamar da linguagem que paga minhas contas, mas sim expressar minha opinião sobre alguns pontos que eu imagino que poderiam ser melhorados no PHP, para que a linguagem cresça e amadureça ainda mais!

 

E vocês, o que acham? A sintaxe do PHP poderia se tornar mais padronizada? Vocês tem opiniões contrárias? Também esperam algum tipo de melhorias? Deixes as opiniões aí!

[Samuel Gomes_148425 19]

a string seria um objeto?

 

ai a gente teria que instanciar ela

e fazer

 

$string->explode

 

O .net é assim, não é

 

 

Achei muito boa sua colocação... Nunca tinha pensado nisso

[Evandro Oliveira 331]

Existem duas palavrinhas mágicas que engessam o desenvolvimento do PHP desde os primórdios:

 

Backward Compatibility

 

Muita coisa não muda porque vai estragar sistemas legados.

 

Pra seguir no mesmo teor da conversa, veja, por exemplo, as funções array_key_exists e array_walk. Numa, o array vem como primeiro argumento. Na outra não.

 

Quanto à questão de tipos nativos, que é debatida há muito pela comunidade, o maior problema está em perder a principal característica do PHP, que é o autocast. Ainda que eu acredite que este autocast possa ser mantido com o uso de wrappers.

 

Envolver um tipo em um wrapper automaticamente gera um problema de conflito entre argumentos passados por valor×referência.

[redstyle 7]

Pelo que li essa nova sintaxe vai ser no php 6.

 

Sobre sistemas legados não vejo problemas já que eles podem continuar rodando em versões do php mais antigas. O problema aqui é manter atualizações de segurança dessas versões antigas.

[Kazzkiq 2]

Pra seguir no mesmo teor da conversa, veja, por exemplo, as funções array_key_exists e array_walk. Numa, o array vem como primeiro argumento. Na outra não.

 

Esse é outro problema comum nas funções, não se tem um padrão de ordem dos argumentos, bem lembrado...

 

 

 

Muita coisa não muda porque vai estragar sistemas legados.

 

Concordo que isso segura a evolução do PHP a muito tempo, e existem algumas funções que estão ativas mas não tem mais utilidade, e ficam tomando espaço no core da linguagem por conta de compatibilidade com sistemas antigos. Mas sinceramente? Deviam arrancar tudo fora e remodelar as coisas, é a única forma de o mercado realmente se reajustar. 90% dos sistemas afetados seriam coisa simples de resolver e sem danos críticos. E nos outros 10% onde os sistemas em PHP são grandes e complexos, com certeza se tem controle total da infraestrutura, ou seja, é só não atualizar o PHP até que se migre tudo corretamente.

 

Isso acontece a todo instante no mundo corporativo, empresas reestruturando sistemas, mudando de linguagens, etc.

 

Na minha opinião é o mesmo problema do IE6, ninguém atualizava os browsers até que os desenvolvedores começaram a deixar de lado o IE6, e então os usuários se viram "obrigados" a migrar para algo melhor. Mão de ferro, eu sei, mas funciona, e muito bem.

 

Se a comunidade for esperar para evoluir a linguagem, ela vai congelar e eventualmente morrer com seus sistemas compatíveis e antigos.

[Enrico Pereira 299]

O PHP precisa de um novo marco, seria o PHP 6, um novo PHP, demoraria uns 5, 10 anos para acabar com o PHP 5, seria outra linguagem, etc.

 

Em ruby, javascript e muitas outras linguagens as coisas são objetos, existe uma RFC para isso, onde podemos criar uma classe e dizer que nossas strings serão uma instância de uma classe. Veja: https://wiki.php.net/rfc/autoboxing

 

Eu acho difícil aprovarem isso, e existem muitas outras coisas muito fodas para o PHP.

 

https://wiki.php.net/rfc

[ESerra 744]

Evoluir a linguagem é necessário, manter a retrocompatibilidade é fundamental. Hoje eu já acho a retrocompatibilidade do PHP lamentável, lançar uma versão nova que simplesmente vai fazer boa parte de tudo ser incompatível com a própria linguagem é apenas dar mais lenha para a já não muito boa fama do PHP.

[William Bruno 1501]

acho mais provavel que migraremos de linguagem, do que a sintaxe do php mudar assim.

[Kazzkiq 2]

Outra coisa é o fato de uma página inteiramente em php precisar da tag de abertura para funcionar, exemplo:

 

umapagina.php

<?php
#só vou ter php aqui, logo, por que preciso abrir a tag php?

 

 

As tags são necessárias quando usadas em conjunto com outra linguagem, como HTML ou XML por exemplo, mas no caso de uma página 100% php isso não é necessário, na verdade gera até problemas se a pessoa fechar a tag php e der um "espaço" depois dela, porque será enviado um cabeçalho de volta ao navegador, mesmo sem a necessidade do mesmo. Exemplo:

 

minhapagina.php

<?php
#código php aqui
?> 

 

se você selecionar o código acima, verá que existe um espaço em branco depois do "?>". Só isso já seria suficiente para enviar um cabeçalho de volta ao user request podendo até atrapalhar o script que estava sendo executado.

[Bruno Augusto 417]

Foi pensando nisso que uns meses atrás eu pensei numa forma Orientada a Objetos de tipagem primitiva para o PHP baseando-me no Java (pelo menos na documentação da API).

Como não sou programador full time, obviamente que não está de todo maduro, mesmo porque eu suspendi o desenvolvimento a fim de documentar tudo aquilo que já existe pronto.

:seta: Download

O uso é bem simples, conforme acompanha o index.php do pacotinho.

Por exemplo, executar uma substituição de texto numa string, seria assim:

try {
 
    $string  = new \Next\Core\Types\String( 'Bruno Augusto' );
 
    var_dump( $string -> replace( 'Augusto', 'Reis' ) -> get() );
 
} catch( InvalidArgumentException $e ) {
 
    echo $e -> getMessage();
}

Existem hoje cinco tipos cada um já com recursos prototipizados "de fábrica": Vou listá-los abaixo com os respectivos métodos:

• Boolean
  • compare()
• Float
  • Ver Number
• Integer
  • convert() - base_convert()
  • Ver Number
• Number
  • max()
  • min()
  • modulus() - fmod()
  • pow()
  • rand() - mt_rand()
  • ceil()
  • floor()
  • format()
  • round()
  • compare()
• String
  • compare() - strcmp()
  • caseCompare() - strcasecmp()
  • explode()
  • find() - strstr()
  • lowerFirst() - lcfirst()
  • pad() - str_pad()
  • repeat() - str_repeat()
  • replace() - str_replace()
  • reverseFind() - strrpos()
  • shuffle() - str_shuffle()
  • striptags()
  • substr()
  • toLower() - strtolower()
  • toUpper() - strtoupper()
  • trim()
  • upperFirst() - ucfirst()
  • upperWords() - ucwords()

E se um recurso precisar estar disponível, basta implementá-lo através de Prototype::implement() Um bom exemplo é a própria definição de Integer::convert() onde simplesmente mapear base_convert() não seria possível haja vista que um objeto String deve ser retornado.

Espero que gostem e contribuam para amadurecer o ideal.

[Enrico Pereira 299]

Quando tivermos auto boxing no PHP (duvido que tenhamos, mas é possível) .. vc vai poder colocar as classes como tratadoras dos primitivos, por exemplo:

 

String -> String

 

Automático, sem precisar instanciar novamente, essa solução é boa pois permite type hinting e encapsula as verdadeiras cacas do PHP (funções nativas).

Outra coisa é o fato de uma página inteiramente em php precisar da tag de abertura para funcionar, exemplo:

 

umapagina.php

<?php
#só vou ter php aqui, logo, por que preciso abrir a tag php?

 

 

As tags são necessárias quando usadas em conjunto com outra linguagem, como HTML ou XML por exemplo, mas no caso de uma página 100% php isso não é necessário, na verdade gera até problemas se a pessoa fechar a tag php e der um "espaço" depois dela, porque será enviado um cabeçalho de volta ao navegador, mesmo sem a necessidade do mesmo. Exemplo:

 

minhapagina.php

<?php
#código php aqui
?> 

 

se você selecionar o código acima, verá que existe um espaço em branco depois do "?>". Só isso já seria suficiente para enviar um cabeçalho de volta ao user request podendo até atrapalhar o script que estava sendo executado.

 

Existe um RFC para isso: https://wiki.php.net/rfc/nophptags

[Bruno Augusto 417]

Confesso que não conhecia esse autoboxing mmas deu pra sacar que seria mais ou menos isso.

[Enrico Pereira 299]

Ele ainda não entrou em votação e acho que não vai ser aprovado.