O que você mudaria no PHP se pudesse ditar a próxma versão (PHP 6)?

[mangakah 217]

Acabei de ver este post no PHPDeveloper.org sobre uma discussão no Reddit sobre essa questão recebeu toneladas de respostas, das quais as selecionadas pelo autor foram:

- Named parameters (aka Keyword arguments. Esse é o que acho que faz mais falta!)

- Add scalar type hinting (atualemtne só é possível com objetos)

- True multi-threading support

- Property accessors

- Strings as objects

- A native namespace

- Return typing

- Default autoloading

Interessante... concordo com todos. Mas eu também adicionaria:

- Multiple Inheritance (Os traits vieram para suprir isso, eu sei, mas algumas vezes é coveniente que uma classe tenha dois ou mais pais)

- Uma forma de dar um switch para tipagem forte ou fraca

- Compilador byte-code

- Possibilidade de estabelecer tempo de execução e consumo de memórias infinitos

- Erros convertidos em Exceções

Mas o que eu mudaria mais mesmo seria uma mudança radical na sintaxe:

- Tudo é objeto e a manipulação desses objetos se daria apenas por chamadas de métodos. Funções soltas nunca mais. Enfim, True OO.

- + para concatanação

- . para acessor de métodos

- Fazer slicing de strings e arrays como em Python

- const para declarar uma constante (em qualquer lugar, não apenas em classes)

- fim do print

- uma mesma sintaxe para todos os drivers de banco de daods relaciona

- fim do require_once, include e include_once. Ficando só require, mas com o funcionamento de require_once

- fim do $

- Case-sensitivity em todos os casos.

- Uma lambda que tenha uma sintaxe melhor do que a create_funcion

- unset e isset como construçao de linguagem ao invés de funçÕes

E você, como responderia essa pergunta?

[Enrico Pereira 299]

- Strings as objects

Não só strings, tudo deveria ser um objeto. Essa é a melhor parte do Ruby.

 

- Default autoloading

- fim do require_once, include e include_once. Ficando só require, mas com o funcionamento de require_once

Nada disso. Sem autoloading, sem require. Um sistema sólido de pacotes como o do Python e do Java.

- Compilador byte-code

Just in time, né?

- Tudo é objeto e a manipulação desses objetos se daria apenas por chamadas de métodos. Funções soltas nunca mais. Enfim, True OO.

Concordo, mas poderíamos ainda ter suporte a criação de funções em runtime, com namespaces e que essas funções sejam objetos e possam ser passadas por parâmetro.

- Multiple Inheritance (Os traits vieram para suprir isso, eu sei, mas algumas vezes é coveniente que uma classe tenha dois ou mais pais)

Essa eu discordo feio, traits já estão suficientes.

http://iamleeg.blogspot.com.br/2006/11/one-reason-multiple-inheritance-sucks.html

- Uma lambda que tenha uma sintaxe melhor do que a create_funcion

Isso já existe desde o 5.3.

- const para declarar uma constante (em qualquer lugar, não apenas em classes)

E que constantes possam ter valores dinâmicos.

- fim do print

E de qualquer alias estúpido.

 

- + para concatanação

- . para acessor de métodos

- fim do $

Not sure if cool or not...

Acho que concatenação não precisa ter símbolo algum e que o $ seja opcional. Não podemos ser tão radicais assim.

 

Vamos aos meus:

 

- Fim do func_get_args. Uma constante mágica __ARGS__ deveria fazer o trabalho.

- Namespaces obrigatórias. Apenas o PHP poderia colocar os comandos básicos na namespace global.

- Propriedades privadas por padrão.

- Semicolon e parêntesis opcionais.

- Poder executar um método fora do construtor, como se faz no Ruby.

- Suporte nativo aos conceitos funcionais.

- XML e JSON como tipos nativos. O mundo usa essa p*rra diariamente.

- Fim da maldita tipagem fraca. 1 carneiro + 1 vaca não pode ser um cálculo válido..

- Request ($_*) e Response (header, setcookie) deveriam ser objetos nativos e não mais funções/variáveis globais obstrutivas.

- Isset retorna true quando o valor é null, afinal null é um valor.

- Nenhuma função retorna false para indicar erro ou true para indicar sucesso.

- Annotations nativamente. Yes, we need.

- Nomes descritivos. Ninguém merece strncmp, etc.

- Sobrecarga de métodos.

- Implode deve ser join e somente join.

- Uma variável, ao ser definida, deve poder apenas ter valores do tipo original.

- Fim do arroba (meio óbvio, já que tudo será exceptions).

- Fim da tag <?php

- Fim do acesso à protegidos e privados na reflection.

- Closures devem poder ser serializadas.

- Monkey Patching através de traits runtime, polêmico, mas..

- Criação de objects e fim dos métodos/propriedades estáticos(as) igual a forma feita em Scala.

- Fim da keyword static, apenas self.

- Campos inexistentes de array retornam null ao serem chamados ao invés de E_NOTICE.

- Mudança nos métodos mágicos:

- Construct e destruct continuariam existindo.

- __toString teria uma interface Stringable e perderia o __. Haveria também a Integerable, Arrayable, etc.

- __call teria uma interface MethodMissing e perderia o __.

- __clone teria uma interface Clonable e perderia o __.

- __invoke teria uma interface Invokable e perderia o __.

- __set, __get, __isset, __unset seria removidos em favor da ArrayAccess

- __sleep e __wakeup seriam removidos em favor da Serializable

- __callStatic (não haveria mais estáticos, como já disse) e __set_state são inúteis.

- Fim das referências, afinal tudo seria objeto.

 

E os fora da linguagem em si:

 

- Centralização do desenvolvimento no GitHub, não mais CVS e SVN.

- Qualquer um que fez qualquer coisa importante na comunidade pode votar nas RFCs se os que votam aprovarem.

- Para votar contra um RFC deve haver justificativa plausível.

- Deve haver um guia oficial para contribuir para o core.

- O PHPT deve ser mais rápido.

- A Zend deve evangelizar o uso de versões mais novas.

 

É bastante coisa e muitas delas praticamente impossíveis de acontecer. Eu acho que nós, desenvolvedores PHP, deveremos nos unir e criar uma nova linguagem (com todo apoio comercial da Zend) baseado em nossos interesses e necessidades.

[cristianoolv 93]

Adiciona enuns, sobrecarga de construtor, obriga o uso de um método main, troca __parent() por super() e voilá, ai é só mudar o nome para JHJ...

 

modo ironico: on. (sem isso, vem uns mangol enchendo o saco!)

 

 

 

Falando serio: Acho um saco usar o $ e toda hora ter que digitar ->....

[Enrico Pereira 299]

Para mim a sintaxe só precisa ser decente. Não é a sintaxe que faz uma boa linguagem ou não.

 

Python não é a melhor linguagem do mundo por ter uma sintaxe "guti-guti" e C não é uma linguagem ruim por ter uma sintaxe um pouco suja.

 

Sempre que vamos expressar "a linguagem que amaríamos" usamos várias outras linguagens como exemplo, mas isso não significa que essas linguagens usadas como exemplo sejam melhores ou piores.

 

ideias > estupidez

[cristianoolv 93]

No quesito produtividade, sintaxe limpa é relevante...

[mangakah 217]

 

 

 

 

 

 

 

Isso já existe desde o 5.3.

É essa aqui né?!

function ($v) use { return $v + $something }

Vacilei.

 

E de qualquer alias estúpido.

Yay!

 

E que constantes possam ter valores dinâmicos.

Aí não seriam mais constantes, mas sim algum tipo de "variável somente leitura" ou algo assim...

- Fim do func_get_args. Uma constante mágica __ARGS__ deveria fazer o trabalho.

Concordo, mas não sei se uma constante mágica seria a melhor opção. Acho que seria melhor uma variável especial (com a $this para objetos, só que para o método) e/ou outra palavra-chave. E que também possibilitasse entrever o nome da variável passada para a função (se fosse o caso), não apenas o valor.

Propriedades privadas por padrão.

Discordo. A maioria das propriedades são públicas, certo? Então nada melhor que este seja o default, para poupar o programador de ter de ficar especificando public várias vezes.

Uma variável, ao ser definida, deve poder apenas ter valores do tipo original.

Isso é interessante. Eu estava pensando que seria uma boa ter uma declaração de tipagem para um determinado arquivo, tipo o "strict mode" do JavaScript, só que este para declarar a tipagem forte. Por exemplo:

use "strong typing";

// Pronto, tipagem forte para esse arquivo!

Mas se for uma regra do tipo: se um tipo for declarado, então é tipagem forte, mas apenas para aquela variável, então é ainda melhor pois mais flexível.

XML e JSON como tipos nativos. O mundo usa essa p*rra diariamente.

Em Scala XML é tipo nativo. Eu adicionaria também YAML e TeX, além de /RegExp/ automaticamente criar um objeto RegExp, como em JS.

- Fim do arroba (meio óbvio, já que tudo será exceptions).

É de se admirar que isso ainda exista.

 

- Fim da maldita tipagem fraca. 1 carneiro + 1 vaca não pode ser um cálculo válido..

Tipagem dinâmica (duck typing like python :)) e tipagem forte se um tipo for definido.

 

 

De resto eu concordo, mas discordo de tudo que você disse depois de "E os fora da linguagem em si:".

[Enrico Pereira 299]

Aí não seriam mais constantes, mas sim algum tipo de "variável somente leitura" ou algo assim...

 

Você me entendeu errado. Não disse que o valor deve ser modificado.

 

Eu disse isso:

const FOO = 'Hehe' . $umaOutraVariavelLegal . 'Haha';
const BAZ = new stdClass;

// Isso não é suportado pelo PHP, por incrível que pareça.

 

 

Discordo. A maioria das propriedades são públicas, certo? Então nada melhor que este seja o default, para poupar o programador de ter de ficar especificando public várias vezes.

 

Não sei não hein. Em Ruby todas as propriedades são protected a não ser que você declare um accessor para ela. Eu acho mais inteligente, veja um (na verdade dois) exemplo:

 

class User
{
    attribute name, email, password
}

$user = new User
$user->name = 'José'
$user->email = 'jose@email.com'
$user->password = '123'

// ....

class Config
{
    function construct(ConfigReader $reader)
    {
        $this->reader = $reader;
    }

    function read($file)
    {
        return $this->reader->read(new SplFileObject($file))
    }
}

$config = new Config(new XmlConfigReader)
$config->read('database.xml')

 

 

 

 

Isso é interessante. Eu estava pensando que seria uma boa ter uma declaração de tipagem para um determinado arquivo, tipo o "strict mode" do JavaScript, só que este para declarar a tipagem forte. Por exemplo:

use "strong typing";

// Pronto, tipagem forte para esse arquivo!

 

Eu não tinha pensado nisso :)

 

 

mas discordo de tudo que você disse depois de "E os fora da linguagem em si:".

 

Por que?

[mangakah 217]

Quanto a visibilidade das propriedades... é bom lembrar que private é bem mais restritivo que protected, né. Mesmo assim, eu sempre achei que o default em todas as linguagens, inclusive Ruby, é public.

 

Você tem algum link aí que discorde?

 

 

Por que?

 

- Centralização do desenvolvimento no GitHub, não mais CVS e SVN.

Bom, eu só acho que os caras que gerenciam o projeto sabem bem o que é melhor para essa tarefa. Como eu sou um mero usuário, não vejo porque me preocupar com isso.

 

- Qualquer um que fez qualquer coisa importante na comunidade pode votar nas RFCs se os que votam aprovarem.

- Para votar contra um RFC deve haver justificativa plausível.

Algo semelhante com o que coloquei acima. Esse caras sabem melhor do que eu qual a melhor política a ser utilizada para alavancar o projeto.

 

 

- Deve haver um guia oficial para contribuir para o core.

Isso seria muito difícil de manter pois rapidamente esse guia ficaria ultrapassado.

 

- O PHPT deve ser mais rápido.

Não sei se entendi bem esse... Eu entendi que você quis dizer com isso que as rotinas de teste deveriam ser mais rápidas, é isso? Se for, então... "A pressa é inimiga da perfeição".

 

- A Zend deve evangelizar o uso de versões mais novas.

Ela já faz isso. O problema é que a adoção das versões mais recentes dependem de vários fatores e a maioria deles está fora da influência da Zend. Não é só uma questão de querer a versão mais recente, há muitos outros fatores que devem ser levados em consideração, inclusive fatores econômicos. E esses sempre falam mais alto. Além disso, esse é um processo que leva tempo. Imagine um grande provedor de hospedagem, com milhares de ser vidores, tendo de atualizar todos eles enquanto mantem os sites de seus clientes no ar...

[Enrico Pereira 299]

Quanto a visibilidade das propriedades... é bom lembrar que private é bem mais restritivo que protected, né. Mesmo assim, eu sempre achei que o default em todas as linguagens, inclusive Ruby, é public.

 

http://rubysource.com/php-developer-on-visibility-and-privates/

 

Em Ruby há atributos (propriedades públicas) e propriedades (que são protected).

 

Nós usamos properties normalmente para dois usos: representar um valor (getter/setter) e armazenar instâncias.

 

Para representar um valor, poderíamos usar uma tag própria:

class User
{
    attribute name, email, password
}

$user = new User
$user->name = 'José'
$user->email = 'jose@email.com'
$user->password = '123'

 

Para armazenar um objeto, não precisaríamos fazer nada a não ser armazená-lo:

class Config
{
    function construct(ConfigReader $reader)
    {
        $this->reader = $reader;
    }

    function read($file)
    {
        return $this->reader->read(new SplFileObject($file))
    }
}

$config = new Config(new XmlConfigReader)
$config->read('database.xml')

 

 

Bom, eu só acho que os caras que gerenciam o projeto sabem bem o que é melhor para essa tarefa. Como eu sou um mero usuário, não vejo porque me preocupar com isso.

 

Algo semelhante com o que coloquei acima. Esse caras sabem melhor do que eu qual a melhor política a ser utilizada para alavancar o projeto.

 

Eles não sabem melhor... isso deve ser mais participativo e justo. Os RFCs são as decisões que mudam o PHP, e afetam todos nós.

 

1º - O GitHub já é um standard de facto de projeto open-source.

2º - O processo de voto das RFCs deve ser mais democrático, isso beneficiaria a comunidade. Afinal, somos nós quem usamos o PHP.

3º - Deveria sim haver uma justificativa para votar contra. Hoje em dia um membro votante pode votar contra uma RFC por uma razão não válida. Ex: Fulano criou uma RFC e Beltrano foi votar nela. Beltrano não gosta de Fulano, logo Beltrano vota contra.

 

 

Isso seria muito difícil de manter pois rapidamente esse guia ficaria ultrapassado.

 

Eu não concordo com isso. O core não muda da noite para o dia.

 

 

Não sei se entendi bem esse... Eu entendi que você quis dizer com isso que as rotinas de teste deveriam ser mais rápidas, é isso? Se for, então... "A pressa é inimiga da perfeição".

 

Não né.... Eu digo a performance dos testes do core (escritos com o PHPT) deveria ser melhor. É frustrante rodar a suíte de testes do PHP, demora muito.

 

--

 

Com o último concordei.

[hinom 5]

As mudanças exigidas seriam muito radicais.. é praticamente como escrever outra linguagem..

 

Outro problema é, o php é feito em boa parte de modo voluntário.. não há grandes financiadores, mas há grandes parceiros que contribuem como o Yahoo, Facebook, IBM, entre outros e milhares de anônimos.

 

Outro ponto é mais filosófico.. o lema do PHP é a flexibilidade (libertinagem) dos códigos.

A questão de aplicar typehint já foi muito discutida mas o dono do PHP sempre recusou aplicar.

 

O PHP é popular como é hoje devido a essa libertinagem. Se fosse mais restritivo (burocrático), provavelmente alguma outra linguagem ascenderia no lugar.. acho que o Phyton..

 

 

Uma crítica

O PHP é aberto, qualquer pessoa pode contribuir na prática implementando os códigos, inclusive no Core.

Quem acha que deve ser "assim ou assado" ou pensa que sabe fazer melhor, então que bote a mão na massa e mostre.

Os developers exigem mudanças no PHP, mas o PHP espera mudanças na mentalidade dos developers também, afinal, usufruem de graça de uma excelente ferramenta e menos de 0.01% contribui para o PHP.

Reciprocidade é importante.

[Vinicius Rangel 208]

vocês estão querendo transformar o php em phyton e java, grande marco do PHP que fez com que muita gente procurasse é o simples fato de você "escrever de qualquer jeito", mas ela te permite orientar a objeto também.

 

agora mudar concatenação e tirar o cifrão pra que?

só pra ficar igual a outra linguagem que vocês conhecem?

[srnalim 21]

No meu ver muitas ideias dadas para adicionar coisas são tiradas de outras linguagens, acho que toda linguagem tem seu pró e contra e eu como programador devo me adaptar atualmente php não me da dor de cabeça então eu deixaria do jeito que ta.

 

E sobre a constante receber o valor de outra variável eu também acho inviável pois como próprio nome já diz "Constante" (não muda, não varia, que consiste). Se uma variável por ter qualquer valor a constante não seria mais constante como outro usuário já diz ela seria apenas uma variável qualquer.

[mangakah 217]

Pessoal, parece que a discussão foi desviada... Quem não quiser responder a pergunta, que ignore esse tópico e vá para outra coisa. <_<

 

 

E sobre a constante receber o valor de outra variável eu também acho inviável pois como próprio nome já diz "Constante" (não muda, não varia, que consiste). Se uma variável por ter qualquer valor a constante não seria mais constante como outro usuário já diz ela seria apenas uma variável qualquer.

 

Também acho... realmente muito estranha essa ideia do Enrico.

[Osmar L Lima 51]

Li todas as respostas e me parece que o foco foi desviado, não transformemos PHP em outra linguagem, certas implementações passadas por vocês são de outras linguagens, para mim particularmente o PHP é suficiente, me atende em todas as situações, é claro que não existe uma linguagem perfeita, todas tem prós e contras, PHP não foge disto, enfim, algumas coisas dependem muito da maneira de se programar e não simplesmente culpa da linguagem.

[srnalim 21]

Justamente Osmar e mangakah seja mais educado ninguém desvio nada apenas dei minha opinião e comentei sobre uma coisa citada aqui e sua importância.

 

mas se fosse pra tirar alguma coisa do php eu tiraria a programação estruturada de vez assim pessoas seriam obrigadas a orientar objetos e talvez se familiarizassem mais em termos de ajuda e outros fatores.

[cristianoolv 93]

agora mudar concatenação e tirar o cifrão pra que?

só pra ficar igual a outra linguagem que vocês conhecem?

 

obj = new Objeto();
obj.setAlgumaCoisa('algumacoi'+numero+'sasetada').setOutraCoisa('outraCoisa').fazAlgo();

$obj = new Objeto();
$obj->setAlgumaCoisa('algumaco'.numero.'isasetada')->setOutraCoisa('outraCoisa')->fazAlgo();

Olha que inutil ficar escrevendo $ e -> toda hora...

A mudança até facilitaria a vida de quem ja sabia programar em outra linguagem oop a se adaptar ao php...

[Vinicius Rangel 208]

virou javascript ¬¬...

php não é javascript e vice-versa.

 

acho mais legível o php ainda.

[01100011cc 15]

Objeto obj = new Objeto(); obj.setAlgumaCoisa('algumacoi'+string+'sasetada').setOutraCoisa('outraCoisa').fazAlgo(); 

Pronto, agora virou Java hehe...

 

Tambem acho chato e inutil o uso do ->, um ponto é bem mais legivel e facil digitação...quanto o $, ele ajuda as pessoas que estão começando, a diferenciar uma variavel, ta certo que em javascript é recomendavel usar var, mais no python é limpinho...

[mangakah 217]

virou javascript ¬¬...

 

php não é javascript e vice-versa.

 

acho mais legível o php ainda.

 

Quer dizer que apenas por trocar -> por ponto e remover o $ o PHP vira JS?? Ai, ai...

 

É mais prático usar o . e não ter de ficar digitando $ toda hora. Isso aumentaria a produtividade.

[srnalim 21]

Vamos concordar que as mudanças citadas é tudo pra deixar o programador mais preguiçoso quer facilidade coisa masi legivel é só abandonar o PHP e atacar outra linguagem que tenha as implementações requeridas.

 

Echo pratico digitar -> ainda mais em teclado ABNT o americano tbem nao é dificil. e nem atrasa e muito menos tira produtividade do programador.