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

88

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.

StasM
la source
9
@ Stan: Même si vous voulez éviter ce genre de commentaire, vous allez l'obtenir quand même. Les problèmes les gens ont avec PHP sont en grande partie dans les catégories de choses que vous êtes au pouvoir dans votre poste. [...]
Fishtoaster
24
[...] Vous dites "Comment pouvons-nous améliorer l'expérience de se faire frapper au visage sans vraiment vous frapper au visage?" Je veux dire, oui, avoir du café gratuit pendant que nous sommes frappés au visage peut être agréable, cela ne résout pas vraiment beaucoup de problèmes sous-jacents avec, eh bien, être frappé au visage. Donc, même si j'espère que vous obtiendrez des réponses utiles ici (comme cela semble déjà être le cas), ne soyez pas surpris par les réponses improductives.
Fishtoaster
5
@Fishtoaster: si PHP s'associe pour être frappé au visage pour vous, éloignez-vous-en. Vous n'êtes certainement pas intéressé à l'améliorer. Il se passe bien qu'il y ait des gens qui le soient. Ce sujet est pour eux, pas pour vous. Je suis sûr que ce site a beaucoup de sujets pour vous aussi, ce n'est tout simplement pas l'un d'entre eux.
StasM
5
Je me sers du visage comme exemple: une situation dans laquelle des améliorations superficielles ne sont pas si importantes; quand les problèmes de la plupart des gens sont avec la chose sous-jacente. Je n'entache même pas votre tentative d'obtenir des suggestions pour ces améliorations superficielles. Je vous explique simplement pourquoi vous risquez d'obtenir quelques réponses inutiles, étant donné la situation.
Fishtoaster
6
@Fishtoaster: De manière surprenante , tout le monde n'aime pas PHP - je l'ai toujours aimé. Très flexible et rapide (à coder).
Orbling

Réponses:

119

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 .

Note to self - pensez à un nom
la source
1
C'est la liste de 2005. De nombreuses idées ont été fermées, puis rené. En fait, si une bonne implémentation arrive, il y a de bonnes chances qu'elle soit acceptée.
StasM
21
C'est ma fonctionnalité préférée de python. Rend le code très auto-documenté.
Keyo
7
@ Josh K: C'est bien possible, mais l'appel à 'array' est une foutaise inutile si vous voulez. Cela ne fait que dissimuler ce que vous essayez VRAIMENT de faire. Une autre option serait une syntaxe abrégée pour les tableaux: make_img (['src' => 'blah.jpg', ...]);
Erik van Brakel
2
@ Erik: Ce n'est pas une mauvaise option non plus, je dis pourquoi ajouter ce fouillis à une langue alors que vous pouvez déjà le faire avec un wrapper de tableau mineur.
Josh K
4
@ Erik: Une syntaxe plus simple pour les tableaux (comme l' []opérateur de JavaScript ) serait une fonctionnalité appréciée.
Josh K
93

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?
Annika Backstrom
la source
18
La syntaxe () [] est déjà dans le tronc. Malheureusement, les raccourcis vers les tableaux ont été rejetés, mais j'espère pour la résurrection.
StasM
2
J'aimerais cette fonctionnalité. Pourquoi pouvons-nous avoir quelque chose_that_returns_object () -> 4, mais pas avec des tableaux?
Bala Clark
4
Javascript, comme les notations de tableaux et d'objets, basculerait. En tant que développeur front-end, c'est ce qui me dérange le plus dans le code php.
Bleep Bloop
1
@DisgruntledGoat Cela fait, voir:function something_that_returns_array() { return array( 'a', 'b', 'c', 'd', 'e' ); }
Annika Backstrom
2
@DisgruntledGoat: Le problème de la ()->syntaxe est qu'il ne fonctionne que lorsqu'un objet est renvoyé. Pour aggraver les choses, il est même nécessaire que l'objet ait une propriété / méthode du nom spécifié, ce qui, de manière optimale, fait ce que vous espérez qu'il fera. , tout en acceptant les paramètres que vous lui avez donnés, et en priant pour que cela ne soit plus nécessaire, etc. etc.
phant0m
72

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!

Funkatron
la source
(2) regardez runkit. (3) Unicode est difficile, d’autant plus que la majorité du monde extérieur n’est pas unicode. Nous devions soit réduire les performances, soit demander aux utilisateurs de faire beaucoup de travail supplémentaire (comme le fait Java). C'est pourquoi l'effort unicode de php6 n'a pas fonctionné.
StasM
8
En ce qui concerne unicode: cela peut être difficile, mais cela serait très utile (développer PHP lui-même est difficile, mais il offre de grands avantages, oui?) Une solution serait peut-être de permettre à unicode transparent via une extension avec le bon compromis, un peu comme XHP? Merci encore.
Funkatron
5
$ object = (object) array ("foo" => 'bar', baz => 'boo');
mercutio
3
Je ne vois pas comment vous pouvez voir que "la plupart du monde extérieur n'est pas unicode"? Parlez-vous des gens? Ou autre chose? Parce que la grande majorité des personnes dans le monde (par une énorme marge) parlent des langues qui sont les mieux représentés par Unicode.
Dean Harding
1
Certainement le support unicode. L'expédition de n'importe quelle application utilisée dans le monde entier est un non-débutant sans elle. Que les développeurs PHP pensent que l’ingénierie dans le support unicode décent est facile ou pas est un problème. Les gens en ont besoin et ils corrigent les erreurs de la plate-forme. Delphi l'a fait en ajoutant un autre type de chaîne et en en faisant le type par défaut, avec une diffusion implicite et un commutateur global permettant de récupérer l'ancien comportement. Pourquoi PHP ne peut-il pas le faire de la même manière?
Joeri Sebrechts
48

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.
davidtbernal
la source
48

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?

Keyo
la source
3
Je pense que array n'étant pas un type d'objet est une grosse erreur en PHP. Conduit à toutes sortes de problèmes. Malheureusement, c'est une chose évolutive. Vous pouvez faire ce que vous voulez ici avec une extension ou un espace utilisateur. Conviendrait probablement bien à SPL.
StasM
3
Le même argument s'applique aux chaînes. Je parle simplement du manque de méthodes en général. Des langages comme Java, Python, C #, etc. ont tous un code bien plus lisible. Je suppose que vous recherchez des fonctionnalités, mais réparer ce qui est endommagé de l'OMI serait plus rentable.
Keyo
6
Non, ne sois pas stupide. Ce seraitdog_wake_up($dog); bark_dog($dog);
Matchu
2
IMHO, toutes les nouvelles méthodes de chaîne doivent s'attendre à émettre UTF-8 et en émettre, et émettre des exceptions si l'entrée n'est pas UTF-8 valide. Cela réduirait considérablement le besoin de retravailler en profondeur le support Unicode.
Rjmunro
1
@luiscubal Non. Un paramètre supplémentaire signifie que nous ne pourrons pas ajouter de paramètres ultérieurement si nous inventons de nouvelles choses à ajouter à la fonction. Par exemple, si $ string => trim () n'indique que des espaces (comme avant 4.1.0), votre système dirait alors $ string => trim ('ISO-8859-1') des espaces rognés à partir de chaînes ISO-8859-1 . Si nous voulions ensuite pouvoir couper des éléments qui n'étaient pas des espaces, nous ne pourrions pas ajouter le paramètre pour cela, à moins que les personnes ne spécifient d'abord l'encodage. Nous devrions encourager les gens à croire que tout texte autre que UTF-8 n’est pas correct .
Rjmunro
40

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.

Nick Berardi
la source
2
Tout ce qui facilite les requêtes paramétrées obtient mon vote!
Dean Harding
1
Je pense que l'accès normalisé à la base de données est en fait un avantage très important de quelque chose comme LINQ, car il facilite les tests unitaires avec des objets
fantaisie
Je ne pense pas que quelque chose comme ceci devrait entrer dans le noyau. cela irait mieux dans une extension de pecl
harald
38

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

ruurd
la source
1
Bien que j'aime bien le principe KISS de PHP (dans une certaine mesure), je l'appuie fortement. La raison en est que si vous voulez être vraiment défensif, vous vous retrouvez avec le même code de vérification de type dans chaque méthode de définition. Nous pourrions facilement laisser tomber cela si le langage le supportait de manière native.
MicE
4
"Type hinting" était un nom très malheureux, car ce n'est pas "hinting", c'est une frappe stricte. Je pense que le typage strict primitif serait déplacé dans un langage dynamique comme PHP. Le typage coercitif (comme les fonctions internes - essayez strlen (123)) peut être correct.
StasM
6
+1 pour cela. Le fait de laisser un indice (ou un typage strict) dans les déclarations de fonction serait extrêmement utile et réduirait d'autant les coûts si (! Is_int ()) est une merde dans la méthode EACH AND EVERY.
Phil Sturgeon
5
@StasM Je ne suis pas d'accord. C’est parfaitement dans le cadre d’un langage dynamique de permettre à l’utilisateur de choisir d’utiliser le langage de manière statique. Et cela permettrait une bien meilleure saisie des erreurs. Vous n'auriez pas à l'utiliser si vous ne le vouliez pas, mais personnellement, j'en ai marre de faire passer des chaînes où je voulais un int, puis de chercher dans le code pour savoir où la chaîne stupide est passée. Ou bien, tapez tout en vérifiant tout le temps.
Daniel Bingham
2
@StasM Il n'y a absolument aucune raison pour que vous ayez à introduire des variables de type complètement statique. Oui, vous déplaceriez les erreurs dans votre code. Ce serait le point entier. L'erreur se produirait au moment de l'appel de la fonction et non à l'intérieur de celle-ci, ce qui ne laisse aucune idée de l'endroit où l'erreur se produit réellement. En ce qui concerne les erreurs de conversion de type, l'erreur se produirait - oui au moment de l'exécution - lors de l'appel de la fonction. Corrigez le problème en convertissant le type correct ici. Bien mieux que d’afficher une chaîne dans une fonction qui attend un int et qui ne sait pas où.
Daniel Bingham
34

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

Emil Stenström
la source
Le support Unicode s’est révélé beaucoup plus difficile que prévu. C'est pourquoi les efforts de php6 ont été bloqués. Pour le moment, nous avons utf-8 et je pense que la meilleure solution consiste à ajouter le support utf-8 aux fonctions de chaîne, peut-être dans le cadre de l'extension intl.
StasM
3
BTW, la citation est incorrecte. Les chaînes PHP sont des tableaux d'octets, mais leur contenu est aussi portable que vous les rendez et ne dépend pas de "l'encodage par défaut" - c'est juste un tableau d'octets, vous les voulez en utf8, put utf8, vous voulez utf16 - mettez utf16. Le lien phpwact.org semble être mort.
StasM
1
J'espère vraiment que l'extension intl sera activée par défaut, afin que les personnes nécessitant UTF-8 (tout le monde ne l'ait pas?) N'aient pas à se battre contre leurs hôtes pour que les fonctions de chaîne se comportent comme prévu.
Emil Stenström
Merci également pour la clarification sur les chaînes. Cela fait un moment que je suis absent de PHP, je suis donc un peu rouillé. J'ai plutôt combattu la guerre unicode avec Python, qui a des problèmes similaires à ceux de PHP, mais les résout en Python 3. Avoir un "ö" suédois dans votre nom est un gâchis :)
Emil Stenström
C'est certainement un domaine dans lequel j'aimerais voir une amélioration.
Nathan Osman
32

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.

rjmunro
la source
up, c'est exactement ce que je vise.
Kemo
1
subject->verb(object), facilite la mémorisation de l'ordre des paramètres.
Ming-Tang
+1 J'ai joué avec la création de ma propre classe de cordes pour faire ce genre de choses, cela rend le codage beaucoup plus facile et vous n'oublierez jamais l'ordre des paramètres.
DisgruntledGoat
2
Alors qu'est-ce qui is_object($string)reviendrait? Cela permettrait soit de réduire considérablement la compatibilité ascendante, soit d’introduire des objets presque non intuitifs, mais pas tout à fait intuitifs.
Tgr
@Tgr: is_object () devrait être déconseillé - Il ne devrait pas y avoir de chose comme "pas un objet". À court terme, il devrait s'agir d'une propriété que vous pouvez désactiver sur n'importe quel objet, et que les constructeurs de chaînes par défaut désactiveraient.
Rmuno
24

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)

Jakefolio
la source
Je déteste avoir à créer une create()méthode qui ne fait rien de spécial juste pour contourner le problème # 1!
Alan Pearce
Je fais de même mais, en utilisant une liaison statique tardive et une superclasse d'objet, chaque classe qui étend ma super-classe a la méthode, par exemple: SomceClass extend SuperObject {}; SomeClass :: create () -> somemethod ();
dukeofgaming
Jetez un coup d'œil à github.com/philsturgeon/php-ps Ce n'est qu'un début, mais avec de l'aide, cela pourrait être très utile.
Phil Sturgeon
1
Il y a aussi un paquet PEAR qui offre un shell interactif pour coder des expériences rapides en PHP - disponible à pear.php.net/package/PHP_Shell
kguest
(new Foo ()) -> bar () fait partie de 5.4. 3) et 4) sont aussi.
StasM
20

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

Grand maître b
la source
37
1). Comprend sont super. Tout a comprend. 2) C'est bon. 3) La modélisation est la fonctionnalité la plus puissante de PHP . Vous forcer à utiliser d'autres conneries de modèles serait un très mauvais coup.
Josh K
8
J'aime bien (1) et (2), mais (3) semble être une étape rétrograde. PHP vous donne le pouvoir de créer des templates, à vous de choisir si vous l'utilisez judicieusement ou non.
geekbrit
11
3 n'a aucun sens - l'incorporation de balises est nécessaire pour tout V dans les frameworks MVC.
Alex
9
J'ai lu cette réponse comme suit: "Cher Père Noël, veuillez faire en sorte que PHP ne soit pas PHP."
Stephen
1
3 est juste, puisque PHP est un langage de templates.
Andrew le
18

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

Annika Backstrom
la source
1
Les constantes de classe font cela, d'ailleurs.
StasM
4
Sérieusement, je ne comprends pas pourquoi ils font que PHP assume des chaînes sans guillemets. C'est la chose la plus stupide jamais. Je choisirais soit E_ERRORou E_PARSE.
BoltClock
14

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 !

David Murdoch
la source
1
Je suis d'accord en principe, mais je ne sais pas comment le faire en pratique :)
StasM
3
@StasM: J'imagine que la première étape serait de faire en sorte que les nouvelles versions des bibliothèques soient espacées et de permettre aux programmeurs (via les paramètres ini) de désactiver les bibliothèques globales actuelles. Je pense qu'un pack de compatibilité conviendrait aux anciennes versions, mais ne devrait pas être très difficile à écrire.
Michał T
13

Les chaînes doivent être des objets

Kemo
la source
1
Je souhaite que je pourrais upvoter cela plus d'une fois.
EricBoersma
13

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.

Ryan Parman
la source
Je suis d'accord, ce arrayobject devrait être supporté pour les fonctions array_ *. mais quel serait le résultat attendu pour quelque chose comme "array_merge" si vous considérez des sous-classes de arrayobject. seriez-vous autorisé à fusionner des instances de la même classe et que renverrait array_merge? un tableau php ou une instance de arrayobject (respectivement c'est sa sous-classe)?
Harald
Je dirais que puisque les données en interne sont un tableau et que ArrayObject le recouvre de fonctionnalités, même les sous-classes de ArrayObject fonctionneraient toujours avec des tableaux en interne. Je m'attendrais à pouvoir fusionner un autre tableau standard ou ArrayObject (ou sous-classe). En ce qui concerne ce qu'il renverrait, je dirais qu'il devrait également renvoyer un nouvel ArrayObject, mais suivez le précédent selon lequel simplexml_load_string () a défini où vous pouvez spécifier le nom de la classe dont le résultat devrait être une instance.
Ryan Parman
12

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

sfrench
la source
2
Je pense que pour (1) quelque chose cuit d'itérateur et de fermeture serait mieux.
StasM
+1 IMHO, cela devrait être inclus dans toutes les langues, ainsi que les itérateurs. Ils sont juste une façon utile de ne pas avoir.
Evan Plaice
empty()est le contraire logique de if ($x), il est donc logique que ce empty('0')soit vrai, parce que if ('0')faux. La seule différence est empty()que ne lève pas d'avis si la variable n'est pas définie.
Andrew le
12

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!

Dave B.
la source
+1 pour final. Clarifier: finalsignifie que la valeur d'une variable peut être définie à l'exécution (contrairement aux constantes, qui doivent être des expressions constantes), mais ne peut être définie qu'une seule fois. Voir aussi C # readonly.
davidtbernal
1
il y a une proposition de getters / setters pour le tronc qui remplacerait le readonly, etc. Des tableaux immuables seraient probablement difficiles à faire.
StasM
Concernant phpaccess, PHP a déjà un "mode sans échec" qui fait ce que vous décrivez.
DisgruntledGoat
11

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.
Johnco
la source
1
1. malheureusement, c'est difficile à faire, mais c'est certainement un bon article à faire 2. wiki.php.net/rfc/propertygetsetsyntax
StasM
@StasM: que diriez-vous de le faire via des annotations? Quelque chose du genre: / ** @get getFoo; @set setFoo; * / private $ foo;
Michał T
9

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).

Mario
la source
5
Je déteste la syntaxe \ namespace, mais c’est une histoire longue et triste, pourquoi cela est devenu vrai et cela ne va probablement pas changer… Probablement si je pouvais changer une seule chose en PHP qui serait mon candidat principal. Mais c'est ce que c'est.
StasM
@StasM: Merci pour les commentaires et désolé d'être impoli avec certaines choses sur PHP, mais je me soucie de PHP; donc très avisé. - J'ai lu un peu sur le raisonnement. Le dilemme des barres obliques inverses n’est pas encore très important, mais il deviendra l’année prochaine lorsque les bibliothèques se répandront. J'espère donc que quelqu'un écrira un analyseur syntaxique qui réécrira \ cargo \ cult \ class \ class \ noms en caractères de soulignement.
mario
Je suis peut-être idiot, mais quelle est la différence si nous utilisons '::' ou '\' pour les espaces de noms?
Michał T
@Pies: Le ::aurait été plus naturel pour n'importe quel langage proche de syntaxe C / C ++. Et `\` n'est pas seulement anormal parmi tous les langages de programmation, mais a des connotations non testées. Quelques discussions précédentes: stackoverflow.com/questions/238550/… ou developers.slashdot.org/article.pl?sid=08/10/26/1610259 et reddit.com/r/programming/comments/79cut/… - Mais dans Décider de le faire sans rétroaction et faire savoir à la communauté des développeurs de l’absorber n’était pas une décision bienvenue.
mario
1
+ 1000000 pour l'héritage multiple.
ts01
8

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.

Alex
la source
1
Il existe déjà un support dans le moteur pour cela et de nombreuses extensions l'utilisent. Vous pouvez également le faire facilement avec set_error_handler () et ErrorException. Méfiez-vous des E_STRICT / E_NOTICE / E_DEPRECATED si ...
StasM
Je suis bien au courant de ces méthodes et elles sont vraiment bidon. J'aimerais une manière unifiée - celle qui inclut E_STRICT / E_NOTICE et autres.
Alex
7

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.

geekbrit
la source
1
En fait, y penser plus, décharger la base de données semble être un scénario intéressant, alors +1 à ce sujet :)
StasM
1
@Stasm, je suppose que vous voulez dire que des requêtes distinctes sont exécutées en tant que processus distincts. Je parle d'une page complexe qui nécessite la génération de page et le calcul d'arrière-plan. Je peux me tromper, mais je ne pense pas qu'il soit possible de générer (par exemple) des opérations de mise à jour de la base de données dans un processus séparé. Cela aurait pour but de faire parvenir la page au demandeur plus rapidement, au lieu d'attendre que tous les traitements qui ne sont pas directement liés à la production de la page se terminent en série. PS .. Merci pour la mise à jour!
geekbrit
7

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 ()).

Pestaa
la source
Oui, des méthodes magiques pour la conversion en caractères s'il vous plaît.
Michał T
7
  • 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.
Kees van Dieren
la source
+1 Comme j'aimerais voir toutes ces choses en PHP.
Jeremy
6

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.

bobah
la source
1
Une sorte de fonctionnalité de vote haut / bas et la possibilité de créer un lien vers le commentaire original dans la réponse seraient certainement bien.
Tgr
5

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.

Orbite
la source
1
Un de mes collègues pense également qu'il pourrait / devrait y avoir d'autres ajouts concernant les fonctions associées; at mentionné sur son compte github: Ce sont l'absence de array_all () et array_any (), qui vérifient si * une condition représentée par un rappel est valable pour tout ou partie des éléments d'un tableau. gist.github.com/44350
kguest
5

Surcharge de l'opérateur:

$result = $MatrixA + $MatrixB * $MatrixC;
MicE
la source
1
Je ne sais pas à quel point cela clique, PHP étant un langage à typage dynamique.
BoltClock
5
Peut-être que cela devrait être fait par des méthodes magiques, comme __add ($ obj), __times ($ obj) etc.
Michał T
il existe déjà en tant que poste PECL: pecl.php.net/package/operator . Il ne devrait pas être trop de travail de le fusionner avec la source principale
Xananax Le
4

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.

eRIZ
la source
Sauf si attrapé, l'exception tuera le script. L'avertissement, sur un serveur de production, sera enregistré et ne sera jamais affiché à l'utilisateur. Changer cette fonctionnalité maintenant casserait beaucoup de scripts parce qu'ils ne sont pas conçus pour l'attraper. (Notez que j'écris des gestionnaires d'erreur pour générer des exceptions moi-même). Désormais, PDO peut émettre des avertissements ou des exceptions: le programmeur décide à l'exécution. Cette fonctionnalité devrait probablement être ajoutée à plusieurs modules.
Reece45
4
  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é!

Mchl
la source
4

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).

Don MacAskill
la source
4

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.

rjmunro
la source