Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
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:
Interessante... concordo com todos. Mas eu também adicionaria:
Mas o que eu mudaria mais mesmo seria uma mudança radical na sintaxe:
E você, como responderia essa pergunta?
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 ->....
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
No quesito produtividade, sintaxe limpa é relevante...
>
>
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:".
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)>
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?
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.
>
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...
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)>
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.
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.
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?
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.
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.
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.
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.
>
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();A mudança até facilitaria a vida de quem ja sabia programar em outra linguagem oop a se adaptar ao php...
virou javascript ¬¬...
php não é javascript e vice-versa.
acho mais legível o php ainda.
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...
>
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.
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.
Echo pratico digitar -> ainda mais em teclado ABNT o americano tbem nao é dificil. e nem atrasa e muito menos tira produtividade do programador.
Mas tu tem que concordar que é muito mais simples apertar um simples . (ponto)
Vamos concordar que as mudanças citadas é tudo pra deixar o programador mais preguiçoso quer facilidade coisa masi legivel .
esse é o objetivo!
Pelo jeito, srnalim deve discordar da "nova" sintaxe para arrays...
Antes era:
$arr = array();
Agora pode ser feito simplesmente assim:
$arr = [];
Ficou muito mais fácil, mais produtivo, legível, etc., principalmente para longas cascatas aninhadas. Mas isso deve deixar o programador preguiçoso, né...?
o $ da uma facilidade de entendimento as variáveis.
o a questão da concatenação é horrível com p + - por que ele começa a dar conflito com operações matemáticas.
você tira 1 caracter (-> vira .) mas ganha uma função inteira de brinde que é inútil.
No javascript toda operação você tem que dar o parseFloat se não ele não soma e sim concatena.
1 capricho ali muda tudoooo e isso não faz sentido por que é BOM se não nem teria tantas boas aplicações e um crescimento absurdo de programadores e da linguagem.
Eu queria poder colocar um adendo aqui.
Quando eu digo constantes dinâmicas eu digo que elas podem ter valores dinâmicos, não que o valor delas possa ser alterado.
Atualmente, usando o const, podemos apenas definir valores estáticos para as constantes, veja:
<?php
const FOO = 'hehe';
const BAZ = 1;
const BAR = true;No exemplo acima, tudo funciona, mas vamos ver o exemplo de baixo:
<?php
const X = new stdClass;
const Y = 'Foo' . 'Bar' . 'Baz';
const Z = 5 * 30;Nenhum dos exemplos acima funciona porque constantes definidas com const são obrigadas a ter um valor estático. Não pode ser um objeto, não pode ser uma string concatenada, não pode ser um cálculo, nada disso, apenas valores estáticos.
E o mesmo se aplica a propriedades definidas fora do __construct.
---------
O grande problema é: o PHP não será quebrado em hipótese alguma. Mudanças radicais na sintaxe destruiria a compatibilidade da linguagem. PHP não é Pyhton para quebrar tudo de uma versão para outra.
Se realmente quisermos algo assim, apenas uma nova linguagem pode nos atender.
---------
Os grandes problemas com a sintaxe:
O símbolo de mais não serve em uma linguagem fracamente tipada, vide Javascript.
O ponto é usado para concatenar, sem chances de substituir o ->, que vem do C.
As soluções que não destruiriam a linguagem:
--------
E pqp, não é porque algumas mudanças façam a linguagem parecer outra em alguns aspectos que significa que a linguagem agora é outra.
E pqp, não é porque algumas mudanças façam a linguagem parecer outra em alguns aspectos que significa que a linguagem agora é outra.
YEAAAH.
nada se cria tudo se copia, pensando por esse lado beleza mas a galera quer mudar tudo, ai também é sacanagem.
e de todos os pontos que você citou eu só não concordo com a relação do ponto e virgula, pelo simples fato de dizer:
Olha, essa linha acabou.. next();
Não só strings, tudo deveria ser um objeto. Essa é a melhor parte do Ruby.
>
Nada disso. Sem autoloading, sem require. Um sistema sólido de pacotes como o do Python e do Java.
Just in time, né?
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.
Essa eu discordo feio, traits já estão suficientes.
http://iamleeg.blogspot.com.br/2006/11/one-reason-multiple-inheritance-sucks.html
Isso já existe desde o 5.3.
E que constantes possam ter valores dinâmicos.
E de qualquer alias estúpido.
>
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:
- 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.
E os fora da linguagem em si:
É 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.