Quelles fonctionnalités aimeriez-vous avoir en PHP?
Puisque c'est la saison des fêtes maintenant et que tout le monde fait des souhaits, je me demande - quelles fonctionnalités de langage vous souhaiteriez PHP aurait ajouté? Je suis intéressé par quelques suggestions/souhaits pratiques pour la langue. signifier:
- Quelque chose qui peut être fait pratiquement (pas: "Je souhaite PHP devinerait ce que mon code signifie et corrigerait les bugs pour moi" ou "Je souhaite que tout code s'exécute sous 5 ms"))
- Quelque chose qui ne nécessite pas de changer PHP dans une autre langue (pas: "Je souhaite qu'ils déposent les signes $ et utilisent l'espace au lieu des accolades" ou "Je souhaite PHP ont été compilés, typés statiquement et avaient # dans son nom ")
- Quelque chose qui ne nécessiterait pas de casser tout le code existant (pas: "Renommons 500 fonctions et changeons l'ordre des paramètres pour elles")
- Quelque chose qui change la langue ou un aspect intéressant de celle-ci (pas: "Je souhaite qu'il y ait une extension pour supporter le protocole XYZ" ou "Je souhaite un bug # 12345 ont finalement été corrigés ")
- Quelque chose qui est plus qu'une diatribe (pas: "Je souhaite PHP ne serait pas si nul"))
Quelqu'un a de bons voeux?
Mod edit: Stanislav Malyshev est un développeur de base PHP.
Cela ne me dérangerait pas les 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, le PHP devs abattre cette idée déjà.
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. Cela ne me dérangerait pas non plus de la syntaxe d'objet plus courte.
$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 fortement avec JS pendant environ 4 ans, il y a quelques choses que je pense PHP ferait bien d'emprunter à JS :
1) notation abrégée pour les tableaux et les objets. Je crois que cela a peut-être été discuté et abattu sur Internals (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 en JS est un grand gain de productivité.
Par exemple:
$arr = [1,2,3,4];
$assoc = [foo=>'bar', baz=>'boo'];
$stdobj = {foo->'bar', baz->'boo'};
Est (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 qu'une certaine inquiétude à propos d'une confusion potentielle avait été soulevée, mais est-ce vraiment plus déroutant que, disons, la notation hérédoc? À tout le moins, faire un objet stdClass en PHP est assez verbeux pour décourager la pratique, je pense.
2) Être capable de redéfinir des fonctions et des méthodes définies précédemment serait vraiment utile. Cela simplifierait notamment les situations d'extension d'une classe et l'instanciation de la nouvelle classe est soit trop complexe, soit peu pratique. Je pense que nous devons cependant éviter de redéfinir les fonctions et méthodes de base/hors espace utilisateur.
En plus de ces deux, je pense que PHP doit supporter de manière transparente unicode. Cela devient de plus en plus un problème pour les développeurs, et les solutions actuellement proposées dans PHP sont déroutantes et souvent non performantes. Rendre toutes les fonctionnalités de chaîne standard non compatibles avec unicode hors de la boîte serait une victoire massive pour les programmeurs PHP.
Merci d'avoir posé la question!
Ce que j'aimerais, en tant qu'ancien apologiste de longue date: [PHP:
- Syntaxe plus courte pour les tableaux. PHP les tableaux sont l'une des fonctionnalités les plus impressionnantes du langage en raison de leur flexibilité, mais c'est un glisser-déposer pour écrire
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. finallysupport- Attributs/annotations. Ceux-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
AuthorizeAttributequi indiquerait qu'un contrôleur ou une méthode d'action nécessite que l'utilisateur soit autorisé. 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 des fonctionnalités réelles dans des commentaires docblock est certainement un hack. - Syntaxe lambda plus courte. Au lieu d'avoir à écrire
function($x){ return $x*2;}, je pourrais peut-être écrire$x => return $x*2, Ou quelque chose. C'est à nouveau quelque chose qui en fait un frein à l'utilisation de cette fonctionnalité. Par exemple$results = array_filter(array(1,2,3), function($a) { return $a % 2; }):vs$results = array_filter(array(1,2,3), $a => return $a % 2 );Le premier a tellement plus de plomberie qui est fondamentalement sans rapport avec le travail que vous essayez d'accomplir. - Un
Decimal(mathématique à virgule fixe) intégré qui prend en charge les opérations mathématiques via les opérateurs normaux serait une sorte de Nice, car nous n'avons pas de surcharge d'opérateur. - MOAR MAGIC METHODS. Les méthodes magiques sont excellentes. Je pouvais voir PHP ajouter une surcharge d'opérateur via des méthodes magiques (je sais que cela n'arrivera jamais). Mais en général, ils fournissent de très bons moyens de se connecter au langage et de faire des choses sympas.
Rendre PHP vraiment orienté objet. L'évolution slap on another global function De PHP doit se terminer.
array_merge(array_filter(array_intersect_key($arr1, $arr2), "is_int"), $arr3);
C'est difficile à lire pour moi. Je dois créer ma propre pile mentale et la compiler en quelque sorte moi-même. Fondamentalement, il devrait être lu à l'envers. $dog->wakeup()->bark(); est facile à lire comparé à bark(wakeup($dog))
$arr1->array_intersect_key($arr2)->array_filter("is_int")->array_merge($arr3);
Vous avez fait le pas vers l'activation de la prise en charge des objets/méthodes maintenant, veuillez l'utiliser dans les fonctions de base PHP.
Renommons 500 fonctions et changeons l'ordre des paramètres pour elles.
Le déplacement de cette fonctionnalité vers les méthodes permettrait de les renommer en en utilisant de manière cohérente. Cela briserait-il toute compatibilité descendante si les chaînes et les tableaux avaient leurs propres méthodes?
Un moteur de requête à langage intégré serait formidable. Un peu comme ce qui est disponible dans .NET appelé LINQ. Cela aiderait à trier des tableaux de données massifs et à normaliser l'accès à la base de données, de sorte que moins d'attaques par injection SQL réussissent.
Oh. Indication de type pour les primitives. Ce serait bien.
Je souhaite vraiment un meilleur support Unicode hors de la boîte. La plupart des langues évoluent dans cette direction mais PHP ont encore d'étranges commandes jonchées de partout.
Les chaînes PHP ne sont que des tableaux d'octets simples. Leur contenu n'est pas portable car il dépend du codage par défaut actuel.
La même chose s'applique à la représentation construite par sérialiser. Il contient une représentation d'octets préfixée par la longueur de la chaîne sans réellement stocker aucune information de codage.
La plupart des fonctions PHP (chaîne) n'ont aucune idée d'Unicode. Pour une liste détaillée incluant le niveau de risque de chaque fonction, reportez-vous à: http://www.phpwact.org/php/ i18n/utf-8
http://blog.ginkel.com/2010/03/php-unicode-support-or-the-lack-thereof/
Créez des chaînes comme des objets, avec des méthodes intégrées pour remplacer celles qui ne sont pas des 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 destinées à gérer les encodages. Si l'entrée n'est pas UTF-8 invalide, une exception doit être levée, même si la sortie de la fonction n'est pas affectée par l'encodage.
1) J'aimerais que les objets nouvellement instanciés retournent "$ this" afin que je puisse chaîne de méthode, $ user = new User ('john') -> setLastName ('Doe') -> save ();
2) Si vous avez déjà utilisé Ruby, et plus récemment le nœud, ils ont un excellent shell interactif (IRB). J'adorerais pour PHP pour en avoir un qui soit réellement utile.
3) Traits/Mixins, mais j'ai entendu dire qu'ils étaient en route.
4) Je veux seconder le tableau court $ myArray = ['mon', 'tableau'];
5) Désignation/ordre cohérent (c'est-à-dire meule de foin d'aiguille)
1) Veuillez vous débarrasser des inclusions (). Les références à d'autres fichiers doivent être des références et ne doivent pas réellement placer le contenu d'un fichier de code source dans un autre. Beaucoup trop de PHP utilisent include () 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 de compilation d'une application PHP dans un seul fichier de bytecode distribuable ou exécutable. Cela améliorera considérablement l'attrait de PHP comme langage de développement commercial. Cela devrait être un composant de base du langage. Ne vous inquiétez pas des fichiers html utilisés pour l'interface graphique d'une application parce que ...
3) veuillez vous débarrasser de la possibilité d'incorporer des balises PHP dans le HTML. Ou au moins de fournir un mode "sans intégration". C'est un gâchis absolu et encourage une mauvaise conception en mélangeant la logique et la présentation de l'application Les développeurs devraient utiliser des modèles pour l'affichage et ne pas gifler les fichiers PHP ensemble et espérer le meilleur.
Signé,
GrandmasterB
ps: n'écoutez pas ce que disent les autres ici, j'ai été sympa toute l'année
Une directive ini pour E_ERROR sur des constantes non définies, plutôt que de supposer qu'il s'agit d'une chaîne avec E_NOTICE.
Normalisez l'espace de noms global avec une convention de nommage bien pensée qui fait sens pour les nouveaux arrivants!
Pour citer notre bien-aimé Jeff Atwood: PHP craint mais peu importe !
1) Syntaxe de tableau/objet plus courte, à la javascript (comme mentionné précédemment)
2) Autoriser les variables const pour permettre le résultat d'un calcul comme le fait define().
3) Chaînage directement depuis le constructeur: new User()->name('Ryan');
4) Déréférencement de tableau: something_that_returns_array()[4];
5) Prise en charge étendue de SPL. SPL fait un travail décent de réimaginer les fonctions de chaîne et de tableau (entre autres) en tant qu'objets. L'expansion du SPL pourrait résoudre beaucoup de reproches concernant le langage si saccadé.
6) L'utilisation de ArrayObject() doit être aussi transparente que l'utilisation de array(). Vous devriez pouvoir faire des choses comme array_filter($array_object_instance) sans 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 de type automatiques étranges. Par exemple, vous ne devriez pas être en mesure de echo un objet SimpleXMLElement sans d'abord le transtyper explicitement en tant que chaîne. Ou au moins, lancez quelque chose quand cela se produit (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 rappels événementiels/asynchrones. Cela est particulièrement important lorsque vous essayez de télécharger des fichiers volumineux via cURL. Au lieu de threads old-skool, quelque chose comme Grand Central Dispatch d'Apple serait Nice. Ou même quelque chose comme JavaScript où vous pouvez faire des demandes asynchrones et définir des rappels.
10) Un nom/ordre cohérent (c'est-à-dire une botte de foin d'aiguille) serait bien, mais je pense que cela pourrait être mieux résolu avec SPL.
11) Un shell PHP Shell interactif officiellement pris en charge, comme IRB. Facebook en a un appelé phpsh qui a été écrit en Python, mais il manque le polissage que j'aimerais voir.
12) Pour l'API Reflection, ajoutez la prise en charge (a) des commentaires docblock sur les constantes (globales et de classe), et (b) la prise en charge de l'analyse des commentaires de type PHPDoc dans une structure de données sensible. Il existe un package PECL appelé "docblock" qui 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 ? dans les noms de fonction - comme Ruby can.
Chaînes doivent être des objets
Je voudrais voir une méthode légitime de création/définition de tableaux CONSTANT. Il existe quelques façons hackées de simuler ce type de fonctionnalité, mais ce serait bien si ce n'était qu'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 qui est 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 que vous souhaitez pour les informations utilisateur. À l'aide d'une bande de boucles for, il gère tout, de la génération de formulaires et de la sensibilisation d'entrée aux 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 modifiable. Bien que je pense que le système est assez sécurisé, je n'aime rien laisser au hasard. Une méthode pour finaliser les tableaux serait bien pour une situation comme celle-ci.
Nouvelle idée !!
Ohhh, j'ai pensé à autre chose que j'aimerais vraiment vraiment en php. Je voudrais une sorte de système pour contrôler les opérations sur les fichiers php et les opérations de répertoire similaires à la façon dont fonctionne .htaccess.
Le fichier .phpaccess devrait 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 dirait à php de vérifier l'origine de tous les scripts en cours d'exécution qui tentent d'opérer 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 de fichier/ou les opérations de socket seront refusées.
Je pense qu'un tel système ferait de l'hébergement virtuel un environnement beaucoup plus sûr. Si vous pouviez en placer un en haut de chaque hôte virtuel, cela réduirait les chances que quelqu'un trouve un moyen de se faufiler à partir d'un hôte virtuel voisin.
Aussi s'il serait bon d'avoir une méthode de sécurisation à l'inverse de cette manière. c'est-à-dire, restreindre la portée des scripts dans un seul répertoire à ce répertoire.
C'est le yin et le yang tu sais!
1) Compréhension de tableau dans le style de Python compréhension de liste:
$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) Rendre empty () ne pas considérer la chaîne '0' comme vraie
Mes deux plus grands souhaits en tant que programmeur inconditionnel PHP:
- Soutenez enfin. C'est un gros gâchis de contourner cela fictivement à travers des drapeaux ou des moyens similaires.
- J'AIMERAIS voir le support sur la syntaxe de C # pour les getters et les setters. Lorsque vous avez beaucoup de getters et de setters, une syntaxe simple telle que C # est un excellent booster de performances au lieu de le faire de la manière Java et écrire des méthodes getter et setter. Les méthodes magiques sont géniales dans les cas où vous voulez créer des membres dynamiquement (par exemple, si vous voulez donner à un rendu de modèle des variables à utiliser), mais ne sont pas bons pour les propriétés normales sur lesquelles vous souhaitez que le IDE à compléter automatiquement, sachez leurs types, etc., 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 ce qui intéresse les développeurs (même si phpreboot va trop loin pour devenir JS).
Méthodologie de développement : Cela améliorerait considérablement la durée de vie de PHP.net si de telles enquêtes étaient réellement prises en compte. Ne prenez plus d’après-midi bon gré mal gré IRC décisions de syntaxe de session.
Caractéristiques individuelles : Certaines ont déjà été mentionnées, mais je brûlerai volontiers du karma pour être encore plus franc ici:
- Type de chaîne Unicode.
- Bigint (voir Python).
- Runkit intégré pour supprimer/renommer/remplacer les fonctions et classes intégrées, qui ne sont pas toujours aussi bien conçues.
- POO moderne
- héritage multiple (au lieu de la complexité pour prendre en charge rarement les cas Edge avec une syntaxe de traits maladroite)
- les scalaires peuvent doubler en tant qu'objets (voir Python), par ex. array () fonctionne comme ArrayObject, ou des chaînes comme SplString (nécessite des méthodes utilisables, toutes les fonctions de chaîne doivent être disponibles en tant que
str::toupper())
- Dépréciez la merde de merde
\syntaxe de l'espace de noms , corrigez l'analyseur syntaxique et adoptez::comme alternative. Vous savez, comme une vraie langue. - Toute variation de LINQ (même si je ne crois pas que vous imaginez une syntaxe sensée)
- ou littéraux XML.
- Débarrassez-vous du comportement d'exécution de php.ini et des commutateurs sémantiques. Cela enlève une partie de l'excitation, c'est vrai, mais bénéficierait aux développeurs et à la base d'utilisateurs.
- Oui, magic_quotes n'est pas encore parti.
- Convertir le bytecode Zend Engine en PBC
Bien que ce ne soit pas évident, je financerais volontiers quelqu'un d'autre pour faire ce dernier, et tuerais php.net comme implémentation principale. :P
Oh, je viens de remarquer, c'est le wiki de la communauté. Il y a donc une chance que vous ne soyez pas réellement ici pour le karma, mais un véritable intérêt. Si tel est le cas, examinez le <b> problème </b> qui nuit gravement à la langue (directorite).
J'aimerais voir l'unification des erreurs et des exceptions en un seul concept (exceptions). C'est génial de pouvoir attraper des exceptions et les écrire dans un journal, pour trouver et corriger les bugs de cette façon. Mais s'il y a quelque chose de fondamentalement incorrect (lire: PHP erreur) dans un chemin de code qui est très rarement atteint, il n'y a pas de bon moyen de canaliser ces informations dans cette 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 ferait de toutes les erreurs des exceptions - idéalement, des exceptions que je peux attraper dans mon code.
- prise en charge des é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 d'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.
PHP me convient très bien car c'est pour faire tomber des sites Web de petite à moyenne taille; Je dois être un peu sans imagination, la seule chose à laquelle je pourrais penser en tant que réponse à cette question serait quelque chose qui la rendrait plus adaptée aux sites à fort trafic.
Je pense en termes de création de processus vers 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 cela peut être simulé, mais n'est pas pris en charge directement dans php à l'heure actuelle.
J'ai vraiment manqué que les types scalaires ne soient pas traités comme des objets, et les objets réels ne peuvent pas agir comme n'importe quel autre type ou objet (sauf pour la chaîne en raison de __toString ()).
Nettoyez les "Notes contributives des utilisateurs" sur http://php.net . Ils sont parfois un vrai gâchis, tout en étant d'une grande valeur en général.
Il existe quelques fonctions de tableau assez décentes en PHP, fournissant une capacité de traitement de liste, avec des rappels et create_function() fournissant un calcul lambda de base.
Le principal problème avec cela, c'est qu'il est beaucoup trop verbeux en PHP, un système sténographique serait excellent, en particulier en ce qui concerne les commandes map/Reduce.
Plus important encore, les fonctions de liste ne sont pas entièrement complètes:
- il n'y a pas de fonction
foldr,array_reduce()fournitfoldl array_map()devrait passer la clé dans le deuxième argument, commearray_walk()le fait- une
array_map_keys()pourrait être utile pour la modification des touches - la compréhension des listes est très maladroite,
range(),array_fill()etarray_fill_keys()ne gère que de nombreux cas, etarray_filter()est distinct
Je ne vise pas à faire PHP dans Haskell, mais PHP est souvent utilisé pour la manipulation de la structure de données de type liste et avoir un ensemble complet d'outils dans ce ce serait utile.
Surcharge de l'opérateur:
$result = $MatrixA + $MatrixB * $MatrixC;
Prise en charge de fichiers volumineux. 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).
Ajouter des exceptions au lieu de produire E_WARNING ... C'est très ennuyeux 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 ce n'est pas très pratique mais c'est très ennuyeux de recevoir:
ATTENTION
ATTENTION
ATTENTION
et je ne peux pas contrôler le flux de code sans écrire mon propre error_handler et chaîne renifler quelle erreur a été produite (autorisation, nom de fichier incorrect ou autre; je ne me soucie pas des autres sources d'erreurs ici) afin de lever l'exception correcte .
J'espère que je n'ai pas à expliquer pourquoi c'est important.
PHP est devenu orienté objet il y a un certain temps et nous, les programmeurs qui utilisent PHP, attendons avec impatience les fonctionnalités OO, sans introduire "goto" ... Quand j'ai découvert que c'était vraiment le cas, j'ai pensait que c'était un jour de poisson d'avril.
Consolider le modèle d'objet - faire en sorte que tous les objets étendent la classe d'objets de base. La classe Object implémenterait (entre autres) toutes les méthodes magiques (donc elles ne seraient plus magiques!)
Déplacer les extensions vers leurs propres espaces de noms - désencombrer l'espace de noms global
$conn = new \MySQLi\Connection();Désactivez la fonction
spl_autoload()! Sérieusement, c'est probablement l'une des plus grandes fonctionnalités de PHP et aussi la plus inutile en même temps.spl_autoloadest le chargeur automatique par défaut, qui prend en charge les espaces de noms et plusieurs extensions de fichier, mais pour une raison inconnue, les noms de fichiers doivent être en minuscules. Il y a un rapport de bogue rempli pour cela , mais le personnel a répondu qu'il ne le corrigerait pas à cause de la compatibilité descendante. Bon ... ce n'est pas comme chaque framework livré avec son propre chargeur automatique, car celui par défaut est paralysé!
Apportez le support de taint à la dernière version et incluez-le dans les versions standard, de préférence activé dans la configuration par défaut http://wiki.php.net/rfc/taint
Cela empêcherait les attaques par injection XSS et SQL en faisant correctement coder les gens.
Les annotations pour PHP serait formidable, une fonctionnalité qui se démarquerait pour les années à venir. Cette fonctionnalité aidera à écrire de grands frameworks avec du code propre.
Je voudrais voir une clause else pour while, for et foreach. Par exemple.:
while (/*condition*/) {
/* display each result */
}
else {
/* condition was never true; display "no results found" message */
}
Le bloc else n'est exécuté que si la condition pour le while était jamais true.
Cela vous éviterait d'avoir à suivre les indicateurs booléens, et cela pourrait peut-être vous aider à réfléchir aux cas limites et aux conditions d'erreur possibles.
Ne vous débarrassez pas des balises ouvertes courtes, en particulier de l'écho = (. Ceci:
<?=$myvar?>
... est bien mieux que ça:
<?php echo $myvar;?>
- J'aimerais un jour voir le type de données, cependant - j'aime aussi la simplicité de ne pas avoir à traiter avec les types de données, c'est une épée à double tranchant pour moi.
espaces de noms!- Surcharge des appels de fonction avec différentes signatures de méthode
- Meilleur support pour les tests unitaires et l'injection de code, PHPUnit est un outil incroyable, ainsi le framework d'injection de code Symfony fait des merveilles ... mais ils viennent tous avec leur propre courbe d'apprentissage.
Il semble que personne n'ait mentionné une sécurité de type optionnelle .
Ce serait formidable de pouvoir écrire du code comme ceci:
<?php
$someVariable = 123;
$someVariable = "Hello World";
int $anotherVariable = 123;
////$anotherVariable = "Hello"; // This must cause runtime exception.
////int $lastVariable = "World"; // This must cause it too.
?>
Un autre exemple:
<?php
// Current style (which must remain).
function SayHello($howManyTimes)
{
if (!is_int($howManyTimes))
{
throw new Exception('Argument $howManyTimes is invalid. An integer was expected, instead of ' . gettype($howManyTimes) . '.');
}
echo str_repeat('Hello', $howManyTimes);
}
// New, optional, style, allowing to have a shorter code.
function SayWorld(int $howManyTimes)
{
echo str_repeat('World', $howManyTimes);
}
SayHello(123);
SayHello("Hello World");
SayWorld(123);
////SayWorld("Hello World"); // This must cause runtime exception.
?>
Autoriser à nommer un fichier à partir de l'appel include, quelque chose comme ça
include('mytemplate.php', 'MyNamespace');
ou
include 'mytemplate.php' use MyNamespace;
Et commencez à nous permettre d'importer ("utiliser") des espaces de noms sans préfixe:
use OtherNamespace as self;
(au lieu d'avoir à importer chaque classe individuelle afin de l'utiliser sans préfixe d'espace de noms)
- Requêtes SQL non bloquantes (comme insérer un journal, mais n'attendez pas le résultat de la requête)
- Requêtes SQL parallèles
juste un rêve
Générateurs. Comme en Python, avec rendement.
Possibilité de lever des exceptions dans __destructor ou __toString. Et, vraiment, y a-t-il une explication pourquoi ce n'est pas possible?
Ce serait bien d'avoir la possibilité de définir le type primitif (bool | boolean, int | integer, float, double, string, object) d'un paramètre dans une méthode car le tableau est autorisé.
Exemple:
courant:
class HttpResponse { public function __construct($version, $statuscode = HttpStatus::OK, HttpResponseHeaders $headers = array(), $body = '');}
espérer:
class HttpResponse { public function __construct($version, integer $statuscode = HttpStatus::OK, HttpResponseHeaders $headers = array(), string $body = ''); }
Je pensais aussi avoir une classe statique Assert qui peut être utile.
prise en charge de l'indication de type pour tous les types et des méthodes magiques _toXXX pour chaque type possible. (L'utilisation courante de php dérive à mon humble avis plutôt pour limiter le jonglage de types/à quelques exceptions près, comme le flotteur de conversion <-> int /)
Certainement la surcharge de méthode en utilisant l'indicateur de type pour différencier les signatures de méthode. Encore plus, je voudrais voir une sorte d '"attributs" de style ASP.NET, de sorte que mes actions de contrôleur dans un framework PHP MVC puissent ressembler à ceci:
/* [HttpGet] */
public function login() {}
/* [HttpPost] */
public function login() {}
PHP a besoin d'une classe de chaîne Unicode immuable. S'assurer que les chaînes d'entrée sont UTF-8 valides et normalisées et qu'elles restent valides devrait être trivial.
$str = new Utf8String('āll īs ōk');
$str = $str->ucwords(); // Āll Īs Ōk
$str = $str->strtolower()->toAscii(); // all is ok
(string) $str; // UTF-8 bytes
Littéraux d'expression rationnelle native, citations qw{}, qq{} Et q{} De style Perl.
La méthode chaînée appelle tous les objets: $object{ ->method1(); ->method2(); ->getPerson()->getName(); }
L'expression de l'instruction: ({echo $a; $a = $a + 1; $a})
COHÉRENT, NON CONFIGURABLE, NE PEUT PAS ÊTRE DÉSACTIVÉ short_open_tags. S'ils ne sont pas configurables, PHP sera plus portable. Voir wha incluant les ERB - balises de style
J'aimerais voir une façon native de définir open_basedir dans les hôtes virtuels en fonction du nom de domaine automatiquement, sans avoir à configurer une directive par hôte (similaire au correctif Jason Greene, mais natif).
S'il vous plaît, des applications globales! Les variables globales de l'application seraient disponibles pour tous les scripts php, une fois initialisées.
Un moyen de libérer la session pour d'autres threads, sans les fermer:
session_start (); $ _ SESSION ['favcolor'] = 'blanc'; session_flush (); // la session est maintenant débloquée afin que d'autres threads puissent l'utiliser // énorme boucle ... $ _ SESSION ['goût'] = 'doux'; // la session se bloque automatiquement à nouveau session_close ();
Peut-être qu'un cache sur disque serait bien, donc nous pouvons précompiler les scripts php manuellement pour une exécution plus rapide. Similaire aux caches de mémoire, mais avec des fichiers sur disque et une génération manuelle (utilisant probablement une nouvelle extension de fichier).
Aussi, quelque chose de similaire à <? Php = $ variable?> Comme raccourci vers <? Php echo $ variable; ?> serait bien (comme dans les balises asp, mais avec les balises short/asp désactivées).
et, évidemment, get_shutdown_functions () et unregister_shutdown_function (). Il n'y a actuellement aucun moyen d'y accéder. Et plus généralement, une prise en charge abstraite de l'empilement de rappels - quelque chose pour unifier spl_autoloads, des fonctions d'arrêt, des gestionnaires d'erreur (actuellement non empilables, mais peut-être ...) etc. Type de register_callback ($ callback, $ stack) et ainsi de suite, avec certains des piles prédéfinies ('autoload', 'shutdown', 'error' ...) appelées par php ou par l'utilisateur lui-même.
ajout de wrappers d'objets pour les extensions utilisant des ressources (curl, ftp, Gd2 ...). Comme
$oFtp = new Ftp();
$oFtp->connect();
$oFtp->close();
- portée lexicale pour lambdas (en utilisant un autre mot-clé puis fonction) (ou syntaxe de bloc pour créer une portée lexicale appropriée?)
- rendre les lambdas dans les propriétés d'objet appelables
- implique toujours un point-virgule avec des accolades fermantes lambda
- putain, ajoutez use () pour les fonctions normales !!
- traits
- capacité d'intercepter instanceof/is_a ()
- générateurs
- ouvrir l'exception pour la modification de l'exécution
- une fonction pour vérifier les interfaces sans l'implémenter
Mes deux premiers désagréments n'ont pas à voir avec PHP, mais avec ses conventions d'utilisation implicites.
'L'extension du nom de fichier' pour le code de bibliothèque (par exemple PEAR/Horde/Zend/etc.) Devrait se terminer sur
.phpsAu lieu de.php. L'avantage de ceci est qu'il sépare clairement le code à exécuter et le code à inclure, ainsi que facultativement tout (votre) code est assez lisible/navigable depuis le serveur. En prime,spl_filename_extensions()peut être utilisé dans votre chargeur automatique pour la commodité des autres.La convention (dans les documents) est que
::Est utilisé aussi bien pour les méthodes statiques que pour les instances, je serais reconnaissant si elles utilisaient::Pour statique et->Pour exemple des trucs. En tant que bonne convention, il y aura toujours de la place pour l'erreur concernant l'interprétation, mais c'est au moins plus clair.
Pour n'en nommer que quelques-uns, j'aimerais également voir ce qui suit:
GetDocComment de Reflection * (ou peut-être une autre variante du nom ou de l'argument) devrait être plus libéral et obtenir uniquement les premiers commentaires (jusqu'à l'espace) au-dessus du type mentionné. En d'autres termes: je n'aime pas le texte verbeux (lire: manger en ligne) alors que je veux vraiment pouvoir fournir le strict minimum dans tout type de commentaire:
//,#ou/* ... */.Liste des espaces de noms utilisés, par ex.
getdefinednamespaces().Le comportement des `` constantes non définies '' devrait être modifiable par une directive ini, par ex. une chaîne vide ou une erreur fatale. Néanmoins, il ne doit jamais être implicitement transformé en chaîne! (c'est comme le; en javascript).
La constante
__CLASS__Devrait également fonctionner automatiquement comme ceci (appelée statiquement)stdClass::__CLASS__ == '\stdClass'. En d'autres termes, au lieu de faire référence à une classe par une chaîne, je veux utiliser une classe et sa constante magique__CLASS__Pour y faire référence. (oui c'est un idefix)Tapez les méthodes de casting et de magie
__fromType($instancetype)et__toType($type). Ainsi, un objet peut être converti en un entier:$y = (int) $xou en un autre objet$y = (BeanWrap) $x. Néanmoins, une implémentation de cela signifie que sur les douze conversions disponibles qui couvrent huit types différents, les noms de ces conversions ne peuvent plus être utilisés comme noms de classe (par exemple, int, binaire, booléen).
Quand j'ai vu ce fil, j'ai pensé qu'il serait utile de mentionner certains articles que j'ai rencontrés.
- Une sorte de Groovy Groovy?. opérateur en PHP: http://justafewlines.com/2009/10/groovys-operator-in-php-sort-of/
- Améliorez les fermetures: http://justafewlines.com/2009/10/whats-wrong-with-php-closures/
Être assez sage pour pas rompre la compatibilité en arrière. J'ai appris l'existence de goto comme mot clé à la dure, je l'utilisais comme nom de méthode, donc une mise à jour de mon code pour php 5.3 a pris 2 ou 3 heures.
Quelque chose comme des rôles pour les classes serait un bon ajout au système d'objets. Rien de compliqué.
class abc { use xyz::method; use uvw::__all; }
Cela choisirait la méthode méthode de la classe xyz et toutes les méthodes de la classe uvm.
L'appel du constructeur doit être utilisable comme objet juste après sa création.
new goodie()->youp();
Laissez les scalaires être traités comme des objets. Si j'essaye de faire $ scalar-> toLower (); pourquoi me dire que je me trompe? Pourquoi ne pas simplement le convertir temporairement en quelque chose comme un type d'objet "scalaire" et passer ensuite à la "méthode non définie" (peut-être pas le faire comme nul)?
Supprimez les ressources de l'espace utilisateur. PHP a maintenant des objets. Tout ce qui est une ressource peut maintenant se trouver dans un wrapper d'objet qui la cache en tant que propriété privée. Il peut être nécessaire d'ajouter des fonctionnalités pour __sleep () et __wakeup (). La plupart des ressources peut être facilement recréé dans un état "similaire". Même s'ils ne le peuvent pas, l'objet PDO ne peut pas être sérialisé: je suppose que la même chose peut être faite avec d'autres objets.
Laissons la communauté PHP faire des votes avec leur code: nous permet de redéfinir les méthodes, classes et fonctions existantes. Le mauvais code pourrira, tout comme en Javascript. Il laissera les gens en utilisant PHP comprendre ce dont ils ont besoin au lieu d'avoir à deviner tout le temps. Les fonctions et fonctionnalités utilisées/remplacées le plus probablement doivent être prises en compte.
Cela a également pour effet secondaire d'impliquer la communauté PHP avec les problèmes UTF (espérons-le UTF-8). Au lieu d'avoir un paramètre à l'échelle du système qui active ou désactive l'Unicode, PHP peuvent remplacer les fonctionnalités dont ils ont besoin uniquement pour leur application.
Faites de _ un séparateur implicite d'espace de noms. Les gens l'utilisent depuis PHP5, laissent les gens construire leur code au lieu de réécrire si pour PHP 5.3. Je ne connais pas la complexité de celui-ci. Je sais qu'il y a d'abord une réflexion sur le code qui fait des noms de classe comme Zend_Exception: Autorisez-le, le développeur devra toujours y accéder en tant que Zend_Exception ou\Zend\Exception et jamais Exception. Traitez-le comme un nom complet au lieu d'une partie seulement.
POO: prenez quelques conseils de Javascript/Actionscript/Python. Les traits semblent prometteurs, mais changer de type dynamiquement à l'exécution serait génial.
Propriétés: Je vois que des discussions sont en cours sur les propriétés, veuillez les implémenter dynamiquement. PHP est censé être un langage dynamique. Nous devrions être en mesure de définir des propriétés (à peu près tout) au moment de l'exécution.
Traitez les constantes comme leur utilisation: variables globales. Les classes/fonctions/espaces de noms correspondent tous à ce projet de loi. Peut-être que lorsque tout le monde commencera à réaliser qu'ils sont tous des globaux en ce moment, il y aura plus d'idées pour résoudre le problème de la présence de tant de variables/constantes globales.
Compilation JIT: Javascript peut le faire et être ultra-rapide. PHP est l'un des rares derrière dans celui-ci.
PHP est censé être optimisé pour "Hypertexte", mais il n'y a pas de moyen facile d'échapper à la sortie en tant que telle. Personnellement, je redéfinirais le 'print' pour faire un htmlspecialchars (). Dans l'ensemble, il se peut que ce soit juste une princesse ou un écho.
Simplifiez php.ini. php.ini est destiné aux administrateurs système, pas aux développeurs. Supprimez les incompatibilités des balises courtes, corrigez-les ou supprimez-les. C'est ennuyeux pour les administrateurs système de pouvoir activer/désactiver les fonctionnalités de la langue pour l'ensemble du système. Et contournez-les lorsque vous essayez de distribuer des logiciels.
Autoriser PHP existe après la fin d'un cycle de demande (pour FastCGI et Apache). Exposez-le sur une API. Autorisez l'administrateur système à désactiver ou limiter cela. (Exigez que le programme php retourne le contrôle) au répartiteur dans les 10 secondes ou il perd son statut persistant).
Faites de PHP un langage de programmation général.
Shortand pour créer des objets {} et des tableaux [], Taje un coup d'oeil à PiHiPi , ils implémentent cela et beaucoup d'autres sucres syntaxiques simples.
14: Autoriser [] à accéder aux propriétés et fonctions des objets. Les fonctions et les classes sont maintenant des citoyens de première classe, non? Faites de [] le moyen de facto (comme javascript/actionscript) pour accéder dynamiquement aux choses sur les objets.
Autoriser PHP code à être PHP modules. Je ne devrais pas avoir à apprendre le C juste pour rendre ma bibliothèque disponible à l'échelle du système dans plusieurs processus. Laissez le = PHP comprend plus celle-ci.
Au lieu de prendre des idées de Java/C, prenez-les davantage de langages dynamiques comme Javascript, Actionscript et Python. Des fonctionnalités plus spécifiques sont répertoriées ci-dessous.
Erreurs fatales: pourquoi la plupart des erreurs ne sont-elles toujours pas récupérables? J'adore la notion d'erreurs de journalisation dans un fichier journal (implémenté à un niveau très élevé). Ce que je n'aime pas, c'est toujours d'entendre parler d'une "page blanche". Je fais beaucoup de vérifications et de déclarations dans mon code pour les éviter: mais quand quelqu'un passe un null au lieu d'un objet à ma fonction, dieu interdise que PHP peut se remettre d'une telle catastrophe sans faire Je fais moi-même is_null (). Bien sûr, c'est une erreur, il semble juste stupide que la plupart des autres langues appellent cela une NullReferenceError/Exception qui peut être traitée et présentée avec plus qu'un simple écran blanc.
À tout le moins, arrêtez d'ajouter des erreurs fatales. J'ai la possibilité de mettre à niveau un grand nombre de serveurs exécutant PHP 5.2, mais je ne peux pas: parce que je n'ai pas le temps de parcourir ~ 200 sites sur chaque serveur pour corriger l'ancien code Moins vous ajoutez de nouvelles erreurs fatales, plus vous avez de chances de rallier des utilisateurs aux nouvelles versions de PHP.
Supprimez autant d'erreurs fatales de la langue que possible. PHP est censé être un langage dynamique: pourquoi tous les autres langages peuvent-ils récupérer de la plupart des erreurs PHP est fatal? Les programmeurs peuvent contourner les erreurs, mais pas si le programme meurt de force après ce que la plupart des langues considèrent comme une exception NullReferenceException.
Rendre les exceptions réactivables. Ainsi, nous pouvons plus facilement mélanger les exceptions et les erreurs.
(Le plus long et le plus improbable) Séparez la discussion sur la langue, la discussion API/module et la discussion interprète. Ils ne devraient pas être aussi intégrés que maintenant. Les problèmes avec l'interpréteur actuel doivent être résolus en dernier. Pypy/Parrot/JVM prennent tous en charge plusieurs langues. V8 ne le fait pas, mais c'est assez rapide pour que certains travaillent à compiler d'autres langages en JavaScript pour fonctionner sur V8 et tirer parti de ses capacités.
En tant qu'interprète/runtime/vm, les objectifs de développement sont un peu différents d'une langue. Avec PHP, on a l'impression d'être un dans le même. Ainsi, les personnes qui essaient de développer d'autres interprètes ont du mal à suivre les discussions lorsque toute la discussion sur la conception du langage est mélangée à la discussion sur l'interpréteur PHP.
En tant qu'interprète, je pense que plus il prend en charge de langues, mieux c'est. Pourquoi ne pouvons-nous pas avoir un <? Python ou un <? Javascript ou un <? Actionscript. Je suis fatigué de réécrire le code dans une autre langue, donc je peux l'utiliser là-bas. Certains essaient déjà de le faire, cela rallierait probablement le soutien d'autres secteurs de la communauté.
Ma fonction numéro un serait
À mon avis, une fonctionnalité récurrente demandée ici, à savoir les types natifs en tant qu'objets, peut être corrigée en créant vos propres classes wrapper. J'ai développé pour mes projets un objet arrayData, un objet stringData, un objet intData, et ainsi de suite ... Cela résout:
- Typage fort: comme ce sont des classes personnalisées, elles peuvent être appliquées
- Surcharge de type: je peux ajouter toutes les méthodes dont j'ai besoin à ma classe arrayData
- Conversion de type: chacune de mes classes a -> toArray (), -> toInt (), -> __ toString (), etc.
- échappement html dans les modèles (les chaînes sont la classe userStringData qui étend la classe stringData).
- les valeurs sont toujours transmises par référence, sauf indication contraire
- la création d'un intData ('chaîne') lève une exception.
- etc (la liste des prestations est encore extrêmement longue)
À mon humble avis, cela est plus avantageux que les types natifs en tant qu'objets, car vous pouvez avoir le nombre exact de méthodes dont vous avez besoin et les appeler à votre guise.
Mais ce qui me manque tellement, c'est la possibilité d'utiliser des opérateurs natifs sur mes objets. Je peux utiliser l'opérateur [] grâce à arrayAccess. Mais je ne peux pas utiliser "+", "-", etc. Si je le pouvais, alors je pourrais faire stringData + stringData (équivalent à $ string. $ String), ou stringData-stringData (équivalent à str_replace ($ str, ' ', $ string)), ou comparer mes types avec ">" et "<=" ...
Mon implémentation actuelle utilise $ intData-> add ($ n), $ intData-> substract ($ n), etc. Lourd, spécialement dans les fonctions où vous pouvez vous attendre à un objet natif int ou intData. Ce qui signifie que je dois vérifier avec instanceOf dans chaque fonction.
En d'autres termes, bien que mes classes soient prêtes, optimisées et agréables, jusqu'à ce que je puisse surcharger les opérateurs, elles ne sont pas beaucoup plus qu'une preuve de concept. Les utiliser dans un projet réel est ennuyeux.
Exposer le nombre de références zval. (Oui, nous pourrions utiliser xdebug_debug_zval , mais en activant Xdebug sur un site en direct, ick.) Cas d'utilisation: magasin d'objets d'enregistrement actif - vous avez des modèles qui correspondent à des ressources externes (comme des lignes de base de données), et sont responsable de la modification de ces ressources. Avoir deux représentations d'objets distinctes pour la même ressource serait mauvais (perte de données en raison d'écritures conflictuelles, etc.), nous avons donc besoin d'une sorte de cache qui peut retourner le modèle de la ressource demandée si elle a déjà été chargée. Cela tuerait le garbage collection, cependant: une dernière référence à l'objet modèle resterait toujours dans le cache, donc itérer à travers un grand ensemble de ressources comme une grande requête DB ou un grand répertoire consommerait rapidement de la mémoire. Cela pourrait être évité si le magasin d'objets pouvait vérifier s'il n'y avait qu'une seule référence à l'objet stocké (le magasin lui-même) et le détruire si c'était le cas.
J'ai besoin de quelques fonctionnalités erlang en php:
- chargement de code à chaud
- des atomes
- correspondance de modèle (inclure le nom des fonctions, instruction de correspondance comme: cas de)
Travailler avec le bytecode: enregistrer, charger, supprimer, etc.
Système d'inclusion flexible
J'aime les progrès et l'évolutivité du php ces derniers jours.
Les nouvelles fonctionnalités introduites dans Java n'ont fait que compliquer les choses plutôt que de les rendre simples.
demande 1: fonction db-connection-pool comme bibliothèque supplémentaire.
demande 2:
Je demande la programmation inverse ajax ou comète ou la fonctionnalité RTMP en tant que bibliothèque intégrée.Ces sont déjà développés pour .net, Java, python et Perl by dojo foundation
Nous avons des choses similaires en php mais pas une solution complète.
- Le modèle d'observateur est également pris en charge dans SPL. mais pas correctement documenté.
- Framework Xajax (bon mais il nécessite une refonte de l'application)
au revoir.
peu de choses qui feraient ma journée
- Conventions de dénomination saines pour les fonctions intégrées.
- Tapez des astuces pour les chaînes et les chiffres
- Indication du type de retour
- E_STRICT activé par défaut
- Traits, mixins et héritage multiple
- Tout est un objet (c'est-à-dire une pureté rubis)
- Add :: support aux espaces de noms
- Meilleur support Windows
- Test hors de la boîte
- Meilleure documentation pour les sous-fonctionnements de exec ()
- Refonte de php.net avec recherche en direct
- Fonctionnalité similaire à Xdebug prête à l'emploi
- Amélioration de la portabilité PEAR - les utilisateurs des gemmes Ruby doivent savoir
Je voudrais vraiment avoir des annotations .. afaik que RFC a été supprimé.
- Prise en charge UTF-8
- Faire le langage entièrement OO, en empruntant le concept Ruby et Python que tout est un objet. J'ai un peu aimé le rfc d'autoboxing. Cependant, il laisse beaucoup trop de liberté pour les développeurs ce qui n'est pas si bon. Mais avec quelques limitations, cela pourrait être un bon ajout à l'évolution du langage.
$ x = tableau (5, 60, 50, 50); $ x-> map (fonction ($ i) {return $ i * 2;}) -> Push (10);
$ p = "une chaîne"; $ q = $ p-> sous-chaîne (0, 10);
etc.
À mon avis, cela peut être fait sans rompre les fonctions mondiales actuelles. Cependant, la plupart d'entre eux deviendront inutiles et pourraient devenir obsolètes au fil du temps.
- Une notation courte pour les tableaux serait bien, mais ce n'est pas critique pour la langue.
Ce serait bien de pouvoir utiliser une classe qui étend iterable dans une boucle foreach, où vous passez une référence à la boucle:
foreach (& $ myclass as $ me) {
echo $ me;
}
Je n'ai pas passé beaucoup de temps à chercher pourquoi cela ne fonctionne pas actuellement, peut-être est-ce lié au fonctionnement des itérables, je n'ai pas enquêté beaucoup plus que simplement remarquer que cela ne fonctionne pas.
Appel de fonction plus rapide
Nous avons call_user_func($f,$a1,$aN), mais il a été remplacé par $f($a1,$aN). Cependant, il n'y a rien de tel pour call_user_func_array($f,$args).
Ma proposition est de créer une syntaxe de langage spécifique pour cela, comme $f{$args}. La raison pour laquelle tout le monde devrait rester à un mile de call_user_func* Est qu'ils sont extrêmement lents et laids dans le sens où il existe de meilleures alternatives.
syntaxe de décantation d'objet
À l'heure actuelle, pour créer un objet à la volée, vous avez besoin de: (object)array('prop'=>'value');. Par convention, nous devrions également avoir object('prop'=>'value');. De plus, des syntaxes courtes seraient pratiques, similaires à JSON.
ne méthode magique pour tous les types
À l'heure actuelle, nous avons __toString(), et beaucoup ont suggéré __toInt/__toFloat/Etc. Mon conseil serait d'implémenter __toType() ou __typecast(), qui comme premier paramètre, le type de données souhaité est passé, par exemple:
class Test {
public function __toType($type){
switch($type){
case 'integer':
return (int)$this->age;
case 'string':
return $this->age.' years';
default:
throw new EUnsupportedTypeException();
}
}
}
Si nous voulions être plus précis, nous pourrions ajouter un autre argument après $ type, à savoir $ class. Vous pouvez donc: if($class=='person')return new Person($this->age);
Spécification du type de données dans foreach
Actuellement, vous pouvez spécifier le type de données d'un argument de fonction PHP, comme ceci:
public function say_hello_to(UserClass $user){
$this->say('Hello, '.$user->name.'!');
}
Ce serait formidable de le faire également dans un foreach:
public function on_enter_office(){
foreach($users as UserClass $user) // <- See UserClass here?
$user>say_hello_to($this);
}
Le "correctif" actuel utilise une fermeture, comme ceci:
public function on_enter_office(){
$users->each(function(UserClass $user){
$user>say_hello_to($this);
});
}
Le correctif prend plus de ressources, plus d'écriture et gâche la portée, d'où la raison pour laquelle une solution native le rendra plus facile, plus propre et probablement plus rapide que le correctif actuel.
Définitions conditionnelles
Cela ne sera probablement pas une fonctionnalité utile pour de nombreuses personnes, mais c'est un excellent moyen de garder le code en cours d'exécution au minimum même lorsqu'il est compatible avec les anciens systèmes, ce qui rend l'exécution plus rapide. Considérez le code suivant:
if (! function_exists ('json_encode')) {function json_encode ($ value, $ options = 0) {// code hérité}}
- La section
// legacy codeEst toujours analysée, donc toute erreur dans celle-ci entraînera la fermeture de PHP. - Son analyse rend également PHP plus lent, même s'il n'en a pas du tout besoin.
- Le code n'est pas intuitif pour les développeurs
- Les moteurs d'analyse IDE seront confus car ils ignorent les instructions if et finissent par lister la fonction deux fois.
La solution? Compilation conditionnelle:
#if PHP_VERSION<5.2
function json_encode($value, $options=0){
// legacy code
}
#endif
inclure une meilleure prise en charge des liens hypertextes, c'est-à-dire une fonction/méthode-classe qui peut être utilisée pour changer l'uri actuel du navigateur. ou pour en créer un totalement nouveau. en utilisant $ _SERVER ['REQUEST_URI'] || $ _SERVER ['PATH_INFO'] pour comprendre la ressource demandée. Cela pourrait faciliter le développement d'applications REST. (selon UriScheme de rfc et son implémentation de schéma par défaut, peut-être permettre d'implémenter d'autres UriSchemes étendant l'UriBase)
Fournissez quelque chose comme une classe UriResource, permettant de demander de petits extraits de fonctionnalité d'une manière qui pourrait également bénéficier aux requêtes http d'un client.
Créez une fonction qui peut être appelée avant et après un modèle, en activant des balises courtes entre ces deux appels de fonction. Entre ces appels de fonction, les seules variables rendues disponibles sont celles passées au premier appel de fonction (sous forme de tableau associatif (à l'aide de l'extrait)). Cela pourrait faciliter le développement de modèles dans php lui-même (cadre sans cadre). Le no-framework PHP Framework MVC
Dans l'ensemble, je pense que les nombreux frameworks php ont certaines similitudes qui pourraient facilement être intégrées dans php de manière courante.
mais whoami :)
- Objets de valeur immuables
- Classes anonymes et/ou classes en tant qu'objets
- Objet intégré équivalent au type de données de chaîne (mentionné précédemment)
- Annotations ou décorateurs de type Python
- Objets singleton comme à Scala
- Erreurs par défaut en tant qu'exceptions (mentionnées précédemment)
- Prise en charge UTF8
- Suppression de global etc
- Principe d'accès unifié - une façon d'appeler les méthodes d'objet et de manipuler les propriétés (voir Scala)