PHP plus: proposta de P++ criaria um dialeto mais rígido

Não é uma bifurcação, mas uma versão mais rígida que pode deixar a bagagem de compatibilidade para trás e adicionar novos recursos mais facilmente


Um novo dialeto do PHP, com o codinome P ++, poderia ser desenvolvido como uma variante mais rigorosa de seu predecessor dinâmico, com recursos mais avançados e menos bagagem.

A proposta, lançada na comunidade PHP pelo cofundador do PHP Zeev Suraski, teria P ++, ou o que for chamado, vivendo ao lado do PHP, mas não vinculado à filosofia histórica do PHP. O P ++ não seria um fork, mas seria inerentemente mais rigoroso e poderia ser mais ousado com compatibilidade com versões anteriores.

Elementos agora considerados ” baggage “, como short tags, podem ser removidos, enquanto recursos complexos, especialmente para linguagens estritamente tipadas, como operadores estritos ou variáveis tipadas, podem ser adicionados sem introduzir a mesma complexidade no dialeto PHP.

Como o próprio PHP, o P++ seria predominantemente para desenvolvimento web do lado do servidor. Espera-se que a versão planejada do PHP 8 estenda o PHP além do desenvolvimento da Web, com um mecanismo just-in-time e interoperabilidade com as bibliotecas C/C ++.

A grande maioria do código em PHP e P ++ seria idêntica. A maioria dos códigos seria compartilhada entre os nós PHP e P++, tanto na origem quanto no tempo de execução. Mas eles teriam implementações diferentes. Os binários serão idênticos.

O que ainda não está claro é como um arquivo seria marcado como um arquivo P++. Provavelmente teria um cabeçalho especial no topo. Os construtores também podem encontrar maneiras de marcar espaços de nome inteiros como P ++, para que as estruturas não precisem marcar cada arquivo como P++.

Estruturas de dados, interfaces de servidor da Web, subsistemas principais e quase todo o resto serão exatamente o mesmo código, independentemente de um arquivo ser executado como PHP ou P++. Ainda assim, duas versões de certas partes do código teriam que ser mantidas. E é provável que o P ++ tenha verificações adicionais em comparação ao PHP. Os desenvolvedores podem combinar e combinar PHP e P++ no mesmo aplicativo. Ambos os dialetos podem ser executados em um único servidor.

Se o P ++ acontecer, isso significaria uma evolução diferente para o PHP. A rigidez e os recursos relacionados ao tipo provavelmente vão no P ++. O viés para compatibilidade com versões anteriores permanecerá em PHP. Recursos não relacionados, como aprimoramentos de desempenho no mecanismo ou desenvolvimentos em extensões, estariam disponíveis em P ++ e PHP.

Zuraski aponta possíveis opções para a linguagem P ++:

  • Ficar com um PHP dinâmico, que não seria aceito pelos proponentes de uma linguagem mais rígida.
  • Evoluindo para um PHP mais rígido, não aceitável para os defensores de uma linguagem mais dinâmica.
  • Bifurcando a base de código, uma perda líquida para todos os envolvidos.
  • Conceber uma solução para atender aos dois públicos, que é o que a proposta de P++ tenta.

As preocupações com a proposta de P ++ incluem:

  • Converter código PHP em P ++ não seria trivial. A verdade é que isso dependerá do que acaba sendo o P ++.
  • Ferramentas PHP não suportam P ++. Mas poderia ser mais simples para os fornecedores oferecer suporte ao P ++, em vez de dar suporte aos granular declare()s ou uma quantidade ilimitada de edições.
  • Quebra de compatibilidade com PHP. Mas fazer isso através de um novo dialeto, em vez de quebrar o próprio PHP, poderia ser mais agradável.

O P++ seria diferente da linguagem Hack do Facebook, que foi construída em PHP, na medida em que:

  • O Hack foi desenvolvido por uma única empresa.
  • O hack e a máquina virtual HHVM que o acompanha e não possuem o grande veículo de distribuição do PHP.

By Paul Krill

Original


Pesquisa: Viabilidade de P ++

Introdução

Há argumentos contínuos sobre se o projeto PHP deve fazer tudo para preservar a compatibilidade com versões anteriores ou continuar adicionando recursos para tornar o PHP uma linguagem mais moderna, com um exemplo de segurança de tipo mais rígida e aprimorada.

Várias sugestões foram feitas para abordar essa divisão percebida. Uma delas é a criação de um “P++” recém-marcado para incluir todos os novos recursos, e talvez seguir o “caminho mais estrito”, enquanto continua mantendo o “PHP” sem alterar a versão original. Como leva tempo, atenção e recursos para verificar se tal direção é viável, faz sentido descobrir se a comunidade interna geral acha que é um empreendimento que vale a pena.

Proposta

A proposta nesta RFC é uma pesquisa simples para verificar se “P++” (com suporte a duas linguagens distintas com dinâmica diferente versus manipulação rigorosa) é uma direção que as pessoas desejam se comprometer a gastar o tempo e a energia do projeto para explorar.

Votos


Viabilidade do P++
Real nameYesNo
ajf (ajf) X
alcaeus (alcaeus) X
beberlei (beberlei) X
brzuchal (brzuchal) X
bukka (bukka) X
bwoebi (bwoebi) X
carusogabriel (carusogabriel) X
cschneid (cschneid) X
dams (dams) X
danack (danack) X
derick (derick) X
doubaokun (doubaokun) X
duncan3dc (duncan3dc) X
galvao (galvao) X
gasolwu (gasolwu) X
girgias (girgias) X
guilhermeblanco (guilhermeblanco) X
heiglandreas (heiglandreas) X
hywan (hywan) X
jasny (jasny) X
jedisct1 (jedisct1) X
jhdxr (jhdxr) X
kalle (kalle) X
kelunik (kelunik) X
kinncj (kinncj) X
krakjoe (krakjoe) X
kriscraig (kriscraig) X
marcio (marcio) X
mbeccati (mbeccati) X
mcmic (mcmic) X
mike (mike) X
mikemike (mikemike) X
narf (narf) X
nikic (nikic) X
ocramius (ocramius) X
pajoye (pajoye) X
patrickallaert (patrickallaert) X
peehaa (peehaa) X
pollita (pollita) X
ramsey (ramsey) X
rasmus (rasmus) X
reywob (reywob) X
rtheunissen (rtheunissen) X
salathe (salathe) X
scorninpc (scorninpc) X
sebastian (sebastian) X
sergey (sergey) X
svpernova09 (svpernova09) X
tianfenghan (tianfenghan) X
trowski (trowski) X
wjx (wjx) X
wyrihaximus (wyrihaximus) X
zeev (zeev) X
Count:053

rfc/p-plus-plus.txt · Last modified: 2019/08/15 08:52 by nikic

PHP.NET

Obrigado por enviar o seu comentário minha jóia!