Quali funzionalità vorresti avere in PHP? [chiuso]

Dal momento che è la stagione delle vacanze ora e tutti fanno i desideri, mi chiedo: quali funzionalità linguistiche vorresti che PHP avrebbe aggiunto? Sono interessato ad alcuni suggerimenti / desideri pratici per la lingua. Per pratica intendo:

1. Qualcosa che può essere praticamente fatto (no: "Vorrei che PHP indovinasse il mio codice e correggesse i bug per me" o "Vorrei che un codice venisse eseguito sotto i 5ms")
2. Qualcosa che non richiede la modifica di PHP in un'altra lingua (non: "Vorrei che abbandonassero $ segni e usassero lo spazio invece di parentesi graffe" o "Vorrei che PHP fosse compilato, digitato staticamente e avesse # nel suo nome")
3. Qualcosa che non richiederebbe la rottura di tutto il codice esistente (non: "Rinominiamo 500 funzioni e cambiamo l'ordine dei parametri per loro")
4. Qualcosa che fa cambiare la lingua o di qualche aspetto interessante di esso (non: "Vorrei che ci fosse l'estensione per supportare il protocollo per XYZ" oppure "Vorrei bug # 12345 sono stati finalmente fisso")
5. Qualcosa che è più di un rant (non: "Vorrei che PHP non facesse così schifo")

Qualcuno ha degli auguri?

Modifica mod: Stanislav Malyshev è uno sviluppatore principale di PHP.

Non mi dispiacerebbe i parametri nominati.

getData(0, 10, filter => NULL, cache => true, removeDups => true);
// instead of:
getData(0, 10, NULL, true, true);

// or how about:
img(src => 'blah.jpg', alt => 'an albino platypus', title => 'Yowza!');

Purtroppo gli sviluppatori di PHP hanno già abbattuto questa idea .

Più dereferenziazione:

echo something_that_returns_array()[4];

Altri hanno menzionato parametri nominati e sintassi dell'array più breve. Non mi dispiacerebbe anche la sintassi degli oggetti più corta.

$a1 = array(1, 2, 3, 4);
$a2 = [1, 2, 3, 4];

$b1 = (object)array('name' => 'foo');
$b2 = {'name' => 'foo'}; // or something?

Dopo aver lavorato con PHP per circa 13 anni, e pesantemente con JS per circa 4, ci sono un paio di cose che penso che PHP farebbe bene a prendere in prestito da JS:

1) notazione abbreviata per array e oggetti. Credo che questo potrebbe essere stato discusso e abbattuto su Internals (quindi sento - non mi piace vedere come è fatta la salsiccia), ma trovo davvero che la notazione letterale per array e oggetti in JS sia un grande vittoria della produttività.

Per esempio:

$arr     = [1,2,3,4];
$assoc   = [foo=>'bar', baz=>'boo'];
$stdobj  = {foo->'bar', baz->'boo'};

(IMHO) è solo molto più facile da scrivere e più pulito di

$arr     = array(1,2,3,4); // not too bad
$assoc   = array("foo"=>'bar', baz=>'boo'); // not too bad either
$stdobj  = new stdClass; // this gets pretty rough
$stdobj->foo = 'bar';
$stdobj->baz = 'boo';

Ho sentito che è stata sollevata una certa preoccupazione per la potenziale confusione, ma in realtà è più confusa di, per esempio, la notazione ereditaria? Almeno, penso che creare un oggetto stdClass in PHP sia abbastanza dettagliato da scoraggiare la pratica.

2) Essere in grado di ridefinire funzioni e metodi precedentemente definiti sarebbe davvero utile. Semplificherebbe in particolare le situazioni estendendo una classe e creare un'istanza della nuova classe è eccessivamente complesso o poco pratico. Penso che dovremmo evitare la ridefinizione delle funzioni e dei metodi core / non-userspace.

Oltre a questi due, penso che PHP debba supportare in modo trasparente Unicode . Questo sta diventando sempre più un problema per gli sviluppatori e le soluzioni attualmente offerte in PHP sono confuse e spesso non performanti. Rendere la funzionalità di stringa standard unicode pronta all'uso sarebbe una grande vittoria per i programmatori PHP.

Grazie per avermelo chiesto!

Cose che vorrei, come ex apologista PHP di lunga data:

1. Sintassi più breve per le matrici. Gli array PHP sono una delle caratteristiche più sorprendenti del linguaggio a causa della loro flessibilità, ma è un tiro da scrivere some_array_method($argity, array('key' => $value));. Credo che questa proposta sia già stata sviscerata nella mailing list di PHP, sfortunatamente.
2. finally supporto
3. Attributi / annotazioni. Questi consentono di aggiungere un comportamento personalizzato a un metodo in modo da consentire il riutilizzo del codice. Ad esempio, in un framework MVC, si potrebbe definire un AuthorizeAttributeche indicherebbe che un controller o un metodo di azione richiede che l'utente sia autorizzato. Il quadro stesso sarebbe responsabile della ricerca degli attributi e della loro azione di conseguenza. Credo che PHPUnit utilizzi già una sorta di attributo inserendoli nei commenti di docblock, che possono essere letti usando la riflessione, ma inserire la funzionalità effettiva nei commenti di docblock è sicuramente un trucco.
4. Sintassi lambda più breve. Invece di dover scrivere function($x){ return $x*2;}, forse potrei scrivere $x => return $x*2, o qualcosa del genere. Questo è ancora qualcosa che rende un po 'trascinabile usare questa funzione. Ad esempio $results = array_filter(array(1,2,3), function($a) { return $a % 2; }):vs $results = array_filter(array(1,2,3), $a => return $a % 2 );Il primo ha solo molto più impianto idraulico che è sostanzialmente irrilevante per il lavoro effettivo che stai cercando di realizzare.
5. Un built-in Decimal(matematica a virgola fissa) che supportasse le operazioni matematiche attraverso gli operatori normali sarebbe abbastanza carino, dal momento che non abbiamo un sovraccarico da parte dell'operatore.
6. METODI MAGICI DEL MOAR. I metodi magici sono fantastici. Ho potuto vedere PHP aggiungere un sovraccarico dell'operatore tramite metodi magici (so che questo non accadrà praticamente mai). Ma in generale, forniscono davvero ottimi modi per agganciarsi al linguaggio e fare cose interessanti.

Rendi PHP veramente orientato agli oggetti. L' slap on another global functionevoluzione di PHP deve finire.

array_merge(array_filter(array_intersect_key($arr1, $arr2), "is_int"), $arr3);

Per me è difficile da leggere. Devo creare il mio stack mentale e compilarlo da solo. Fondamentalmente dovrebbe leggere al contrario. $dog->wakeup()->bark();è facile da leggere rispetto abark(wakeup($dog))

$arr1->array_intersect_key($arr2)->array_filter("is_int")->array_merge($arr3);

Hai fatto il passo verso l'abilitazione del supporto oggetto / metodo ora per favore usalo nelle effettive funzioni PHP di base.

Rinominiamo 500 funzioni e cambiamo l'ordine dei parametri per esse.

Lo spostamento di questa funzionalità sui metodi consentirebbe loro di essere rinominati usando alcuni in modo coerente. Romperebbe la retrocompatibilità se stringhe e array avessero i loro metodi?

Un motore di query integrato nella lingua sarebbe fantastico. Un po 'come quello che è disponibile in .NET chiamato LINQ. Aiuterebbe l'ordinamento attraverso enormi matrici di dati e standardizzerebbe l'accesso al database, in modo che meno attacchi SQL injection abbiano successo.

Oh. Tipo di suggerimento per i primitivi. Sarebbe carino.

Vorrei davvero un supporto Unicode pronto all'uso. Molte lingue si muovono in quella direzione ma PHP ha ancora strani comandi disseminati dappertutto.

Le stringhe PHP sono solo array di byte semplici. Il loro contenuto non è portatile in quanto dipende dalla codifica predefinita corrente.

Lo stesso vale per la rappresentazione creata da serialize. Contiene una rappresentazione di byte con prefisso di lunghezza della stringa senza effettivamente memorizzare alcuna informazione di codifica.

La maggior parte delle funzioni di PHP (stringa) non ha idea di Unicode. Per un elenco dettagliato comprendente il livello di rischio di ciascuna funzione, fare riferimento a: http://www.phpwact.org/php/i18n/utf-8

http://blog.ginkel.com/2010/03/php-unicode-support-or-the-lack-thereof/

Crea stringhe come oggetti, con metodi integrati per sostituire quelli non nominati e parametrizzati in modo incoerente. per esempio

$subject->replace($search,$replace);
$string->split($separator);
$string->trim();

eccetera.

Modifica: un'altra cosa: questi metodi dovrebbero sempre prevedere ed emettere UTF-8, ad eccezione di quelli specificamente previsti per gestire le codifiche. Se l'input non è valido UTF-8, dovrebbe essere generata un'eccezione, anche se l'output della funzione non sarà influenzato dalla codifica.

1) Mi piacerebbe che gli oggetti appena istanziati restituissero "$ this" in modo da poter eseguire il metodo chain, $ user = new User ('john') -> setLastName ('Doe') -> save ();

2) Se hai mai usato ruby ​​e il nodo più recente, hanno una grande shell interattiva (IRB). Mi piacerebbe che PHP ne avesse uno effettivamente utile.

3) Tratti / Mixin, ma ho sentito che stanno arrivando.

4) Voglio secondare l'array corto $ myArray = ['my', 'array'];

5) Denominazione / ordine coerenti (ad es. Pagliaio dell'ago)

1) si prega di sbarazzarsi di include (). I riferimenti ad altri file dovrebbero essere riferimenti e non posizionare effettivamente il contenuto di un file di codice sorgente in un altro. Troppi programmatori PHP usano include () come un tipo di chiamata di funzione piuttosto che un mezzo per fare riferimento a una libreria. Questo porta a ogni sorta di ambiguità nello stato variabile e nel codice instabile. Sostituiscilo con un comando "usa" simile al Perl.

2) Si prega di fornire un out of the box metodo di compilazione un'applicazione PHP in un unico file bytecode distribuibile o eseguibile. Ciò migliorerà notevolmente il fascino di PHP come linguaggio di sviluppo commerciale. Questo dovrebbe essere un componente di base della lingua. Non preoccuparti dei file html utilizzati per la GUI di un'applicazione perché ...

3) si prega di sbarazzarsi della possibilità di incorporare i tag PHP in HTML. O almeno fornire una modalità "no embed". Questo è un casino assoluto e incoraggia la cattiva progettazione mescolando insieme logica dell'applicazione e presentazione. Gli sviluppatori dovrebbero utilizzare i modelli per la visualizzazione e non mettere insieme i file PHP e sperare nel meglio.

firmato,

GrandmasterB

ps: non ascoltare ciò che dicono gli altri qui, sono stato carino tutto l'anno

Una direttiva ini E_ERRORsu costanti indefinite, piuttosto che assumere che sia una stringa E_NOTICE.

Normalizza lo spazio dei nomi globale con una convenzione di denominazione ben ponderata che abbia senso per i nuovi arrivati!

Per citare il nostro amato Jeff Atwood: PHP fa schifo ma non importa !

Le stringhe dovrebbero essere oggetti

1) Sintassi più breve di array / oggetti, come JavaScript (come menzionato in precedenza)

2) Consenti constalle variabili di consentire il risultato di un calcolo come define()fa.

3) Concatenare direttamente dal costruttore: new User()->name('Ryan');

4) Dereferenziazione di array: something_that_returns_array()[4];

5) Supporto SPL espanso. SPL fa un buon lavoro nel reinventare le funzioni stringa e array (tra le altre cose) come oggetti. L'espansione di SPL potrebbe risolvere molte lamentele sul fatto che la lingua sia così stravagante.

6) L'uso ArrayObject()deve essere trasparente come l'uso array(). Dovresti essere in grado di fare cose come array_filter($array_object_instance)senza farlo array_filter($array_object_instance->getArrayCopy()). Anche meglio, ovviamente, sarebbe $array_object_instance->filter().

7) Unicode completo sarebbe carino.

8) Smetti di fare strane conversioni di tipo automatico. Ad esempio, non dovresti essere in grado di echocreare un oggetto SimpleXMLElement senza prima averlo digitato in modo esplicito come stringa. O almeno, lancia qualcosa quando succede (ad es. In modalità rigorosa o qualunque sia la modalità error_reporting(-1)).

9) Supporto per più thread o una sorta di callback con evento / asincrono. Ciò è importante soprattutto quando si tenta di caricare file di grandi dimensioni tramite cURL. Invece di thread vecchio stile, qualcosa come Grand Central Dispatch di Apple sarebbe bello. O anche qualcosa di simile a JavaScript in cui è possibile effettuare richieste asincrone e definire callback.

10) La denominazione / ordine coerente (ad es. Pagliaio ad ago) sarebbe bello, ma penso che questo potrebbe essere risolto meglio con SPL.

11) Una shell PHP interattiva ufficialmente supportata, come IRB. Facebook ha una chiamata phpshche è stata scritta in Python, ma manca dello smalto che vorrei vedere.

12) Per l'API di Reflection, aggiungi il supporto per (a) commenti docblock su costanti (globale e di classe) e (b) supporto per l'analisi di commenti simili a PHPDoc in una struttura di dati sensibile. Esiste un pacchetto PECL chiamato "docblock" che tenta di farlo, ma non sembra che l'autore sia andato molto lontano.

EDIT: 13) Mi piacerebbe anche vedere la capacità di usare !e ?nei nomi delle funzioni - come può fare Ruby.

1) Comprensione dell'array nello stile di comprensione dell'elenco Python:

$newlist = array($x->something for $x in $oldlist);

//with short array syntax:
$newlist = [$x->something for $x in $oldlist];

2) Sintassi dell'array breve

$newlist = [1,2,3,4,...];

3) Rendi vuoto () non considerare la stringa '0' come vera

Vorrei vedere un metodo legittimo per creare / definire array COSTANTI. Ci sono alcuni modi per simulare questo tipo di funzionalità, ma sarebbe bello se fosse solo una caratteristica di PHP. Sarebbe bello se si potesse creare un array in modo simile alla dichiarazione "finale" di Java.

Ho creato un sistema di accesso che è molto veloce da configurare. Tutto quello che devi fare è cambiare il contenuto di un array in un file di testo per specificare i campi desiderati per le informazioni dell'utente. Utilizzando una serie di cicli for gestisce tutto, dalla generazione di moduli e sensibilizzazione dell'input, alle chiamate al database, ma tutto dipende da questo array originale.

Il file con l'array viene bloccato con autorizzazioni, ma una volta che l'array si sposta nell'etere è mutabile. Sebbene ritenga che il sistema sia piuttosto sicuro, non mi piace lasciare nulla al caso. Un metodo per finalizzare le matrici sarebbe utile per una situazione come questa.

Nuova idea!!

Ohhh, ho pensato a qualcos'altro che mi sarebbe davvero piaciuto in php. Vorrei un qualche tipo di sistema per controllare le operazioni dei file php e le operazioni di directory simili al modo in cui funziona .htaccess.

Il file .phpaccess dovrebbe attivare alcuni tipi di dominio / criteri di origine uguali.

Ad esempio, se ospitassi molti siti con host virtuali, potrei avere un file .phpaccess in una directory che direbbe a php di controllare l'origine di tutti gli script in esecuzione che stanno cercando di operare sulla mia directory protetta. Se lo script non proviene da quella directory o dalle sue sottodirectory, le operazioni sui file / o sui socket verranno negate.

Penso che un sistema come questo renderebbe l'hosting virtuale un ambiente molto più sicuro. Se si potesse collocare uno di questi nella parte superiore di ciascun host virtuale, si ridurrebbe la possibilità che qualcuno trovi un modo per intrufolarsi da un host virtuale vicino.

Anche se sarebbe bene avere un metodo per proteggerlo al contrario di questo modo. vale a dire, limitare la portata degli script in una singola directory a quella directory.

È lo yin e lo yang che sai!

I miei due più grandi desideri come programmatore PHP hardcore:

1. Sostieni finalmente. È un grande casino aggirare immaginariamente questo attraverso bandiere o mezzi simili.
2. Mi piacerebbe vedere il supporto sulla sintassi di C # per getter e setter. Quando hai molti getter e setter, una semplice sintassi come quella di C # è un ottimo booster di prestazioni invece di farlo nel modo Java e scrivere metodi getter e setter. I metodi magici sono fantastici nei casi in cui si desidera creare membri in modo dinamico (ad esempio, se si desidera dare a un renderer di modelli alcune variabili da utilizzare), ma non sono utili per le proprietà normali su cui si desidera che l'IDE si completi automaticamente, conoscere i loro tipi e così via. ciò contribuirebbe a rendere il codice più piccolo, comunque leggibile e facile da usare.

Sintassi del linguaggio : ci sono alcuni buoni indizi in pihipi e phpreboot di ciò che gli sviluppatori sono interessati (anche se phpreboot si spinge troppo oltre diventando JS).

Metodologia di sviluppo : migliorerebbe notevolmente la durata di vita di PHP.net se tali sondaggi fossero effettivamente presi in considerazione. Non prendere più decisioni sulla sintassi della sessione IRC pomeridiana.

Caratteristiche individuali : alcune sono state menzionate in precedenza, ma brucerò felicemente un po 'di karma per essere più schietto qui:

• Tipo di stringa Unicode.
• Bigint (vedi Python).
• Runkit builtin per rimuovere / rinominare / sovrascrivere funzioni e classi integrate, che non sono sempre così ben progettate.
• OOP moderno
  • ereditarietà multipla (anziché complessità per supportare raramente casi limite con sintassi di tratti goffi)
  • gli scalari possono raddoppiare come oggetti (vedi Python), ad esempio array () funziona come ArrayObject o stringhe come SplString (necessita di metodi utilizzabili, tutte le funzioni stringa dovrebbero essere disponibili come str::toupper())
• Deprecare la \sintassi dello spazio dei nomi di merda di merda , correggere il parser e adottare ::come alternativa. Sai, come una vera lingua.
• Qualsiasi variazione di LINQ (anche se non mi fido di voi ragazzi escogitate una sintassi ragionevole)
• o letterali XML.
• Sbarazzarsi del comportamento di runtime php.ini e degli switch semantici. Elimina un po 'di entusiasmo, vero, ma gioverebbe a sviluppatori e utenti.
• Sì, i magic_quotes non sono ancora spariti.
• Converti il ​​bytecode di Zend Engine in PBC

Anche se, se ciò non fosse ovvio, finanzerei felicemente chiunque altro per fare quest'ultimo, e uccidere php.net come implementazione principale. :P
Oh, ho appena notato, è wiki della community. Quindi c'è la possibilità che tu non sia qui per il karma, ma un interesse genuino. In tal caso, esaminare il <b> problema </b> che danneggia gravemente la lingua (directorite).

Mi piacerebbe vedere l'unificazione di errori ed eccezioni in un unico concetto (eccezioni). È fantastico essere in grado di rilevare le eccezioni e scriverle in un registro, per trovare e correggere i bug in quel modo. Ma se c'è qualcosa di fondamentalmente sbagliato (leggi: Errore PHP) in un codepath che viene colpito molto raramente, non c'è un buon modo per incanalare quelle informazioni nello stesso database di problemi.

Per favore, Babbo Natale, introduce un interruttore in php.ini che trasformerebbe tutti gli errori in eccezioni - idealmente, eccezioni che posso catturare nel mio codice.

PHP mi sta benissimo, così come lo è per abbattere siti Web di piccole e medie dimensioni; Devo essere un po 'privo di immaginazione, l'unica cosa che potrei pensare come risposta a questa domanda sarebbe qualcosa che la riduca meglio per i siti ad alto traffico.

Sto pensando in termini di spawn di processi ad altri core, ad esempio l'aggiornamento di un database in un processo mentre si crea la pagina di output in un altro processo. Una rapida ricerca su Google indica che questo può essere simulato, ma al momento non è supportato direttamente in php.

Mi è davvero mancato che i tipi scalari non siano trattati come oggetti e gli oggetti reali non possono agire come qualsiasi altro tipo o oggetto (tranne la stringa dovuta a __toString ()).

• supporto per le enumerazioni (come java 1.5+)
• Essere in grado di definire i tipi di restituzione del metodo, in interfacce e classi
• supporto per la definizione di annotazioni / metadati su proprietà e metodi.
• essere in grado di eseguire suggerimenti di tipo rigoroso per argomenti scalari di metodo.

Pulisci "Note fornite dall'utente" su http://php.net . A volte sono un vero casino, pur essendo un grande valore in generale.

Ci sono alcune funzioni di array abbastanza decenti in PHP, che forniscono capacità di elaborazione delle liste, con callback e che create_function()forniscono un calcolo lambda di base.

Il problema principale è che è troppo prolisso in PHP, un sistema abbreviato sarebbe eccellente, in particolare per quanto riguarda i comandi map / ridurre.

Ancora più importante, le funzioni dell'elenco non sono completamente complete:

• non c'è alcuna foldrfunzione, array_reduce()forniscefoldl
• array_map()dovrebbe passare la chiave nel secondo argomento, come array_walk()fa
• una array_map_keys()potrebbe essere utile per la modifica chiave
• la comprensione dell'elenco è molto complessa range(), array_fill()e array_fill_keys()gestisce solo così tanti casi ed array_filter()è separata

Non sto puntando a far entrare PHP in Haskell, ma PHP è spesso usato per manipolare la struttura dei dati di tipo elenco e avere un set completo di strumenti in questo senso sarebbe utile.

Sovraccarico dell'operatore:

$result = $MatrixA + $MatrixB * $MatrixC;

Aggiungi eccezioni invece di produrre E_WARNING ... È molto fastidioso non poter usare qualcosa come:

try{
   $f = fopen('asd', 'r');
   flock($f, LOCK_SH);

   while(!feof($f)){
       echo fread($f, 512);
   }

   fclose($f);

}catch(IOException $ex){
   echo 'Oops, something wrong: '.$ex->getCode();
}

Naturalmente, attualmente non è molto pratico ma è molto fastidioso ricevere:

AVVERTIMENTO

AVVERTIMENTO

AVVERTIMENTO

e non riesco a controllare il flusso di codice senza scrivere il mio gestore_errore e annusare la stringa quale errore è stato prodotto (permesso, nome file errato o altro; non mi dispiace per altre fonti di errori qui) al fine di gettare la corretta eccezione .

Spero di non dover spiegare perché è importante.

PHP è diventato orientato agli oggetti un po 'di tempo fa e noi programmatori che usano PHP non vediamo l'ora di vedere le funzionalità di OO, non introducendo "goto" ... Quando ho scoperto che è successo, ho pensato che fosse un pesce d'aprile.

1. Consolida il modello a oggetti: estendi tutti gli oggetti alla classe di oggetti base. La classe Object avrebbe (tra le altre cose) implementato tutti i metodi magici (quindi non sarebbero più magici!)

2. Sposta le estensioni nei loro spazi dei nomi: disordinare lo spazio dei nomi globale $conn = new \MySQLi\Connection();

3. Disattiva la spl_autoload()funzione! Seriamente, questa è forse una delle più grandi caratteristiche di PHP e anche la più inutile allo stesso tempo. spl_autoloadè il caricatore automatico predefinito, che supporta spazi dei nomi ed estensioni di file multiple, ma per qualche ragione sconosciuta richiede che i nomi dei file siano minuscoli. È stato compilato un rapporto sui bug per questo , ma il personale ha risposto che non lo riparerà a causa della retrocompatibilità. Giusto ... non è come se ogni framework venisse fornito con il proprio caricatore automatico, dato che quello predefinito è paralizzato!

Supporto di file di grandi dimensioni. Abbastanza per favore?

Vedi http://bugs.php.net/bug.php?id=27792 (anche se potrebbero esserci più aree / funzioni che richiedono attenzione).

Porta il supporto taint all'ultima versione e includilo nelle build standard, preferibilmente attivato nella configurazione predefinita http://wiki.php.net/rfc/taint

Ciò impedirebbe attacchi di iniezione XSS e SQL rendendo il codice persone corretto.