Quelles fonctionnalités voudriez-vous avoir en PHP? [fermé]

Comme nous sommes à l’heure des fêtes de fin d’année et que tout le monde fait des voeux, je me demande quelles fonctionnalités linguistiques souhaiteriez-vous que PHP aurait ajoutées? Je suis intéressé par quelques suggestions pratiques / souhaits pour la langue. Par pratique je veux dire:

1. Ce qui peut être fait pratiquement (pas: "Je souhaite que PHP devine ce que signifie mon code et corrige des bugs pour moi" ou "Je souhaite que tout code soit exécuté sous 5 ms")
2. Quelque chose qui ne nécessite pas de changer PHP dans une autre langue (pas: "Je souhaite qu'ils lâchent des signes $ et utilisent de l'espace au lieu d'accolades" ou "Je souhaite que PHP soit compilé, typé de manière statique et qu'il ait # dans son nom")
3. Quelque chose qui n'exigerait pas de casser tout le code existant (pas: "renommons les fonctions 500 et changeons l'ordre des paramètres")
4. Quelque chose qui fait changer la langue ou d' un aspect intéressant de ce (pas: « Je souhaite qu'il y ait extension à l' appui pour le protocole XYZ » ou « Je souhaite bug # 12 345 ont finalement été fixés »)
5. Quelque chose qui est plus qu'un délire (pas: "Je souhaite que PHP ne suce pas si mal")

Quelqu'un a de bons voeux?

Mod edit: Stanislav Malyshev est un développeur PHP de base.

Cela ne me dérangerait pas des paramètres nommés.

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!');

Malheureusement, les développeurs PHP ont déjà rejeté cette idée .

Plus de déréférencement:

echo something_that_returns_array()[4];

D'autres ont mentionné des paramètres nommés et une syntaxe de tableau plus courte. La syntaxe d'objet plus courte ne me dérangerait pas non plus.

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

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

Après avoir travaillé avec PHP pendant environ 13 ans et surtout avec JS pendant environ 4 ans, je pense que PHP aurait intérêt à emprunter deux choses à JS:

1) notation abrégée pour les tableaux et les objets. Je crois que cela a peut-être été discuté et abaissé sur des composants internes (donc j'entends - je n'aime pas voir comment la saucisse est faite), mais je trouve vraiment, vraiment, que la notation littérale des tableaux et des objets dans JS est un gros problème. gain de productivité.

Par exemple:

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

Est-ce (IMHO) juste beaucoup plus facile à écrire et plus propre que

$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';

J'ai entendu dire que certaines inquiétudes au sujet de la confusion potentielle avaient été soulevées, mais est-ce vraiment plus déroutant que, par exemple, la notation Heredoc? À tout le moins, créer un objet stdClass en PHP est suffisamment détaillé pour décourager la pratique, à mon avis.

2) Pouvoir redéfinir des fonctions et des méthodes préalablement définies serait vraiment utile. Cela simplifierait particulièrement les situations d'extension d'une classe et l'instanciation de la nouvelle classe est trop complexe ou peu pratique. Je pense cependant que nous devrions éviter la redéfinition des fonctions et méthodes de base / non-espace utilisateur.

En plus de ces deux logiciels, je pense que PHP doit prendre en charge de manière transparente l’unicode . Cela devient de plus en plus un problème pour les développeurs, et les solutions actuellement proposées en PHP sont déroutantes et souvent non performantes. Rendre immédiatement prête à l'emploi toutes les fonctionnalités de chaîne standard compatibles avec l'unicode constituerait un gain énorme pour les programmeurs PHP.

Merci d'avoir posé la question!

Ce que je voudrais, en tant qu'ancien apologiste PHP de longue date:

1. Syntaxe plus courte pour les tableaux. Les tableaux PHP sont l’une des fonctionnalités les plus intéressantes du langage en raison de leur souplesse, mais c’est un problème d’écriture some_array_method($argity, array('key' => $value));. Je crois que cette proposition a déjà été éviscérée sur la liste de diffusion PHP, malheureusement.
2. finally soutien
3. Attributs / annotations. Celles-ci vous permettent d'ajouter un comportement personnalisé à une méthode de manière à permettre la réutilisation du code. Par exemple, dans un framework MVC, on pourrait définir un type AuthorizeAttributequi indiquerait qu'un contrôleur ou une méthode d'action requiert l'autorisation de l'utilisateur. Le cadre lui-même serait chargé de rechercher les attributs et d’agir en conséquence. Je crois que PHPUnit utilise déjà une sorte d'attribut en les mettant dans des commentaires docblock, qui peuvent être lus en utilisant la réflexion, mais mettre la fonctionnalité réelle dans les commentaires docblock est certainement un hack.
4. Syntaxe lambda plus courte. Au lieu de devoir écrire function($x){ return $x*2;}, je pourrais peut-être écrire $x => return $x*2ou quelque chose du genre. C’est encore une fois quelque chose qui rend difficile l’utilisation de cette fonctionnalité. Par exemple $results = array_filter(array(1,2,3), function($a) { return $a % 2; }):contre $results = array_filter(array(1,2,3), $a => return $a % 2 );le premier a tellement plus que la plomberie est fondamentalement sans rapport avec le travail réel que vous essayez d'accomplir.
5. Une fonction intégrée Decimal(calcul à virgule fixe) prenant en charge les opérations mathématiques par l'intermédiaire d'opérateurs normaux serait plutôt agréable, car nous n'avons pas de surcharge d'opérateurs.
6. MÉTHODES DE LA MAGIE. Les méthodes magiques sont géniales. Je pouvais voir PHP ajouter une surcharge d'opérateur via des méthodes magiques (je sais que cela n'arrivera pratiquement jamais.) Mais en général, elles fournissent de très bons moyens pour accrocher le langage et faire des choses cool.

Faites de PHP vraiment orienté objet. L' slap on another global functionévolution de PHP doit prendre fin.

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

C'est difficile pour moi de lire. Je dois créer ma propre pile mentale et la compiler moi-même. Fondamentalement, il convient de lire à l'inverse. $dog->wakeup()->bark();est facile à lire par rapport àbark(wakeup($dog))

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

Vous avez franchi le pas vers l'activation de la prise en charge des objets / méthodes, veuillez l'utiliser dans les fonctions PHP principales.

Renommons 500 fonctions et modifions leur ordre de paramétrage.

Déplacer cette fonctionnalité vers des méthodes permettrait de les renommer de manière cohérente. Est-ce que la compatibilité en amont serait brisée si les chaînes et les tableaux avaient leurs propres méthodes?

Un moteur de requête en langage intégré serait formidable. Un peu comme ce qui est disponible dans .NET appelé LINQ. Cela aiderait à trier des ensembles massifs de données et à normaliser l'accès aux bases de données, de sorte que moins d'attaques par injection de SQL réussissent.

Oh. Type de conseil pour les primitives. Ce serait bien.

Je souhaite vraiment un meilleur support unicode prêt à l'emploi. La plupart des langues évoluent dans cette direction, mais PHP contient toujours d’étranges commandes.

Les chaînes PHP ne sont que des tableaux d'octets simples. Leur contenu n'est pas portable car il dépend du codage actuel par défaut.

La même chose s'applique à la représentation construite par sérialiser. Il contient une représentation d'octet avec le préfixe de longueur de la chaîne sans stocker aucune information de codage.

La plupart des fonctions PHP (string) n'ont aucune idée de Unicode. Pour obtenir une liste détaillée comprenant le niveau de risque de chaque fonction, consultez le site http://www.phpwact.org/php/i18n/utf-8.

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

Créez des chaînes objet comme, avec des méthodes intégrées pour remplacer les noms non-objets nommés et paramétrés de manière incohérente. par exemple

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

etc.

Edit: encore une chose: ces méthodes doivent toujours attendre et émettre UTF-8, à l’exception de celles spécifiquement conçues pour traiter les encodages. Si l'entrée est invalide UTF-8, une exception doit être levée, même si la sortie de la fonction ne serait pas affectée par le codage.

1) J'aimerais que les objets nouvellement instanciés renvoient "$ this" afin que je puisse utiliser une chaîne de méthodes, $ utilisateur = nouvel utilisateur ('john') -> setLastName ('Doe') -> save ();

2) Si vous avez déjà utilisé ruby, et plus récemment noeud, ils ont un super shell interactif (IRB). J'aimerais que PHP en ait un qui soit réellement utile.

3) Traits / Mixins, mais j'entends dire qu'ils sont en route.

4) Je veux seconder le tableau court $ myArray = ['my', 'array'];

5) Nom / ordre cohérent (c.-à-d. Aiguille de foin)

1) s'il vous plaît se débarrasser de includes (). Les références à d'autres fichiers doivent être des références et ne pas placer le contenu d'un fichier de code source dans un autre. Beaucoup trop de programmeurs PHP utilisent includes () comme type d'appel de fonction plutôt que comme moyen de référencer une bibliothèque. Cela conduit à toutes sortes d'ambiguïtés dans l'état variable et le code instable. Remplacez-le par une commande 'use' de type Perl.

2) veuillez fournir une méthode prête à l'emploi permettant de compiler une application PHP dans un seul fichier bytecode distribuable ou exécutable. Cela augmentera considérablement l'attrait de PHP en tant que langage de développement commercial. Cela devrait être une composante de base du langage. Ne vous inquiétez pas des fichiers HTML utilisés pour l'interface graphique d'une application, car ...

3) veuillez vous débarrasser de la possibilité d’incorporer des balises PHP dans HTML. Ou du moins, fournissez un mode «sans intégration». C'est un gâchis absolu qui encourage une mauvaise conception en mélangeant la logique d'application et la présentation. Les développeurs doivent utiliser des modèles pour l’affichage et non pas slap les fichiers PHP ensemble et espérer le meilleur

Signé,

Grand maître b

ps: n'écoute pas ce que disent les autres ici, j'ai été gentil toute l'année

Une directive ini pour E_ERRORles constantes non définies, plutôt que de supposer que c'est une chaîne avec E_NOTICE.

Normalisez l'espace de noms global avec une convention de nommage bien pensée qui a du sens pour les nouveaux venus!

Pour citer notre bien-aimé Jeff Atwood: PHP est nul, mais ce n'est pas grave !

Les chaînes doivent être des objets

1) Syntaxe tableau / objet plus courte, à la manière de JavaScript (comme mentionné précédemment)

2) Laisser les constvariables permettre le résultat d'un calcul comme le define()fait le fait.

3) Chaînage direct du constructeur: new User()->name('Ryan');

4) déréférencement de tableaux: something_that_returns_array()[4];

5) Prise en charge SPL étendue. SPL fait un travail décent en réimaginant des fonctions de chaîne et de tableau (entre autres) en tant qu'objets. Expanser SPL pourrait résoudre beaucoup de problèmes de langage si janky.

6) L'utilisation ArrayObject()doit être aussi transparente que l'utilisation array(). Vous devriez être capable de faire des choses comme array_filter($array_object_instance)sans le faire array_filter($array_object_instance->getArrayCopy()). Encore mieux, bien sûr, serait $array_object_instance->filter().

7) Unicode complet serait bien.

8) Arrêtez de faire des conversions automatiques bizarres. Par exemple, vous ne devriez pas pouvoir utiliser echoun objet SimpleXMLElement sans le convertir explicitement au préalable en chaîne. Ou du moins, lancez quelque chose quand cela arrive (par exemple, en mode strict ou quel que soit le mode error_reporting(-1)).

9) Prise en charge de plusieurs threads ou d'une sorte de rappel événementiel / asynchrone. Cela importe surtout lorsque vous essayez de télécharger des fichiers volumineux via cURL. Au lieu des threads old-skool, quelque chose comme le Grand Central Dispatch d'Apple serait bien. Ou même quelque chose comme JavaScript, où vous pouvez faire des requêtes asynchrones et définir des rappels.

10) Un nom / ordre cohérent (c.-à-d. Aiguille d'une botte de foin) serait bien, mais je pense que cela pourrait être mieux résolu avec SPL.

11) Un shell PHP interactif officiellement supporté, comme IRB. Facebook en a un phpshqui a été écrit en Python, mais il manque le vernis que j'aimerais voir.

12) Pour l'API Reflection, ajoutez le support pour (a) les commentaires de docblock sur les constantes (global & class), et (b) le support pour l'analyse de commentaires de type PHPDoc dans une structure de données sensible. Un paquet PECL appelé "docblock" tente de le faire, mais il ne semble pas que l'auteur soit allé très loin.

EDIT: 13) J'aimerais aussi voir la possibilité d'utiliser !et ?de nommer des fonctions - comme Ruby can.

1) Compréhension de tableau dans le style de compréhension de liste Python:

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

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

2) syntaxe de tableau court

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

3) Assurez-vous que empty () ne considère pas la chaîne '0' comme vraie

J'aimerais voir une méthode légitime pour créer / définir des tableaux CONSTANT. Il existe quelques moyens astucieux de simuler ce type de fonctionnalité, mais ce serait bien s'il ne s'agissait que d'une fonctionnalité directe de PHP. Ce serait bien si vous pouviez créer un tableau d'une manière similaire à la déclaration "finale" de Java.

J'ai créé un système de connexion très rapide à configurer. Tout ce que vous avez à faire est de modifier le contenu d'un tableau dans un fichier texte pour spécifier les champs souhaités pour les informations de l'utilisateur. Utilisant une bande de boucles for, il gère tout, de la génération de formulaire à la sensibilisation des entrées, en passant par les appels de base de données, mais tout dépend de ce tableau d'origine.

Le fichier avec le tableau est verrouillé avec des autorisations, mais une fois que le tableau se déplace dans l'éther, il est mutable. Bien que je pense que le système est assez sécurisé, je n'aime pas laisser les choses au hasard. Une méthode pour finaliser les tableaux serait bien pour une situation comme celle-ci.

Nouvelle idée!!

Ohhh, j'ai pensé à quelque chose d'autre que j'aimerais vraiment en php. Je voudrais une sorte de système pour contrôler les opérations de fichiers php et les opérations de répertoire similaire à la façon dont fonctionne .htaccess.

Le fichier .phpaccess doit déclencher une sorte de même domaine / même politique d'origine.

Par exemple, si j'hébergeais de nombreux sites avec des hôtes virtuels, je pourrais avoir un fichier .phpaccess dans un répertoire qui indiquerait à php de vérifier l'origine de tous les scripts en cours d'exécution qui tentent de fonctionner sur mon répertoire protégé. Si le script ne provient pas de ce répertoire ou de ses sous-répertoires, les opérations sur les fichiers / ou les opérations sur les sockets seront refusées.

Je pense qu'un système comme celui-ci ferait de l'hébergement virtuel un environnement beaucoup plus sûr. Si vous pouviez placer l'un de ces éléments en haut de chaque hôte virtuel, cela réduirait les chances de trouver un moyen de se faufiler à partir d'un hôte virtuel voisin.

Aussi, s'il serait bon de disposer d'un moyen de le sécuriser à l'inverse de cette manière. c'est-à-dire, limiter la portée des scripts d'un seul répertoire à ce répertoire.

C'est le yin et le yang tu sais!

Mes deux plus grands voeux en tant que programmeur PHP hardcore:

1. Soutenez enfin. C'est un gros bazar que de contourner fictivement cela par des drapeaux ou des moyens similaires.
2. J'adorerais voir un support sur la syntaxe de C # pour les accesseurs et les setters. Lorsque vous avez beaucoup de getters et de setters, une syntaxe simple, telle que celle de C #, est un excellent accélérateur de performances au lieu de la faire en Java et d'écrire des méthodes de getter et de setter. Les méthodes magiques sont géniales dans les cas où vous voulez créer des membres de manière dynamique (par exemple, si vous voulez donner des variables à un moteur de rendu de gabarit), mais ne conviennent pas aux propriétés normales sur lesquelles vous souhaitez que l'EDI se complète automatiquement, types, et ainsi de suite. cela aiderait à rendre le code plus petit et toujours aussi lisible et facile à utiliser.

Syntaxe du langage : Il existe de bons indices dans pihipi et phpreboot de l’ intérêt des développeurs (bien que phpreboot devienne trop difficile pour devenir JS).

Méthodologie de développement : La prise en compte de telles enquêtes améliorerait grandement la durée de vie de PHP.net. Ne prenez plus de décisions de syntaxe de session IRC d'après-midi bon après-midi.

Caractéristiques individuelles : Certains ont déjà été mentionnés, mais je brûlerai volontiers du karma pour le rendre plus direct:

• Type de chaîne Unicode.
• Bigint (voir Python).
• Runkit intégré pour supprimer / renommer / remplacer les fonctions et les classes internes, qui ne sont pas toujours bien conçues.
• POO moderne
  • héritage multiple (au lieu de la complexité pour prendre en charge des cas rares avec une syntaxe de traits maladroits)
  • les scalaires peuvent être utilisés comme objets (voir Python), par exemple, array () fonctionne comme ArrayObject, ou les chaînes comme SplString (nécessite des méthodes utilisables, tous les funcs de chaînes devraient être disponibles en tant que str::toupper())
• Obsolète la \syntaxe de l'espace de noms merdique , corrige l'analyseur et adopte ::comme alternative. Vous savez, comme une vraie langue.
• Toute variante de LINQ (bien que je ne vous fais pas confiance, vous devez concevoir une syntaxe raisonnable)
• ou littéraux XML.
• Débarrassez-vous du comportement d'exécution et des commutateurs sémantiques php.ini. Certes, cela enlève une partie de l'excitation, mais profiterait aux développeurs et à la base d'utilisateurs.
• Oui, magic_quotes n'est pas encore parti.
• Conversion du bytecode de Zend Engine en PBC

Bien que, si cela n'est pas évident, je financerais volontiers quelqu'un d'autre pour le faire, et tuerais php.net comme principale implémentation. :P
Oh, je viens de remarquer que c'est un wiki de communauté. Il est donc possible que vous ne soyez pas ici pour le karma, mais pour un intérêt sincère. Si tel est le cas, examinez le <b> problème </ b> qui blesse gravement le langage (directoritis).

J'aimerais voir l'unification des erreurs et des exceptions dans un seul concept (Exceptions). C'est génial de pouvoir attraper les exceptions et de les écrire dans un journal pour trouver et corriger les bugs de cette façon. Mais s'il y a quelque chose de fondamentalement faux (lire: Erreur PHP) dans un chemin de code qui est très rarement touché, il n'y a pas de bon moyen de canaliser cette information dans la même base de données de problèmes.

S'il vous plaît, Père Noël, introduisez un commutateur dans php.ini qui transforme toutes les erreurs en exceptions - idéalement, des exceptions que je peux comprendre dans mon code.

PHP me convient parfaitement car il permet de dynamiser des sites Web de petite à moyenne taille; Je dois être un peu peu imaginatif, la seule chose à laquelle je puisse penser comme une réponse à cette question serait quelque chose qui améliore sa taille pour les sites à fort trafic.

Je pense en termes de génération de processus dans d'autres cœurs, par exemple la mise à jour d'une base de données dans un processus tout en créant la page de sortie dans un autre processus. Une recherche rapide sur Google indique que ceci peut être simulé, mais n'est pas supporté directement dans php pour le moment.

J'ai vraiment manqué que les types scalaires ne sont pas traités comme des objets, et que les objets réels ne peuvent pas agir comme n'importe quel autre type ou objet (sauf pour string en raison de __toString ()).

• support pour les énumérations (comme java 1.5+)
• Être capable de définir des types de retour de méthode, dans des interfaces et des classes
• prise en charge de la définition des annotations / métadonnées sur les propriétés et les méthodes.
• être capable de faire des indications de type strictes pour les arguments scalaires de la méthode.

Nettoyez "User Contributed Notes" sur http://php.net . Ils sont parfois un véritable gâchis, tout en étant une grande valeur en général.

Il existe quelques fonctions de tableau assez convenables en PHP, fournissant une capacité de traitement de liste, des rappels et create_function()fournissant un calcul lambda de base.

Le problème principal, c’est qu’il est beaucoup trop détaillé en PHP, un système de sténographie serait excellent, en particulier en ce qui concerne les commandes map / reduction.

Plus important encore, les fonctions de liste ne sont pas entièrement complètes:

• il n'y a pas de foldrfonction, array_reduce()fournitfoldl
• array_map()devrait passer la clé dans le deuxième argument, comme le array_walk()fait
• un array_map_keys()pourrait être utile pour la modification de clé
• la compréhension de la liste est très maladroit, range(), array_fill()et array_fill_keys()ne traiter tant de cas, et array_filter()est séparé

Je ne cherche pas à intégrer PHP dans Haskell, mais PHP est souvent utilisé pour la manipulation de structure de données de type liste. Il serait utile de disposer d'un ensemble complet d'outils à cet égard.

Surcharge de l'opérateur:

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

Ajouter des exceptions au lieu de produire E_WARNING ... C'est très ennuyant de ne pas pouvoir utiliser quelque chose comme:

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();
}

Bien sûr, actuellement n’est pas très pratique mais c’est très ennuyant de recevoir:

ATTENTION

ATTENTION

ATTENTION

et je ne peux pas contrôler le flux de code sans écrire mon propre error_handler et la chaîne qui détecte l'erreur qui a été générée (permission, nom de fichier incorrect ou quoi que ce soit d'autre; les autres sources d'erreurs ne me dérangent pas) afin de générer l'exception correcte .

J'espère que je n'ai pas à expliquer pourquoi c'est important.

PHP est devenu orienté objet depuis un certain temps et nous, les programmeurs qui utilisent PHP, sommes impatients de voir les fonctionnalités d’OO, sans introduire "goto" ... Lorsque j’ai appris que c’était vraiment arrivé, j’ai pensé que c’était un poisson d’avril.

1. Consolider le modèle d'objet - obliger tous les objets à étendre la classe d'objet de base. La classe Object implémenterait (entre autres) toutes les méthodes magiques (pour qu'elles ne soient plus magiques!)

2. Déplacer les extensions vers leurs propres espaces de noms - désencombrer l'espace de noms global $conn = new \MySQLi\Connection();

3. Désactivez la spl_autoload()fonction! Sérieusement, c'est peut-être l'une des plus grandes fonctionnalités de PHP et aussi la plus inutile en même temps. spl_autoloadest l'autoloader par défaut, qui prend en charge les espaces de noms et les extensions de fichiers multiples, mais pour une raison inconnue, les noms de fichiers doivent être en minuscules. Un rapport de bogue a été rempli pour cela , mais le personnel a répondu qu'il ne le corrigerait pas en raison de la compatibilité ascendante. C'est vrai ... ce n'est pas comme si chaque framework était livré avec son propre autoloader, celui par défaut étant paralysé!

Prise en charge de gros fichiers. Jolie s'il-vous-plaît?

Voir http://bugs.php.net/bug.php?id=27792 (bien qu'il puisse y avoir plus de zones / fonctions qui nécessitent également une attention particulière).

Amenez le support de taint jusqu'à la dernière version et incluez-le dans les versions standard, de préférence activées dans la configuration par défaut http://wiki.php.net/rfc/taint

Cela empêcherait les attaques par injection XSS et SQL en rendant le code correct aux utilisateurs.