Concernant le trunk, les modifications qu'il a subit sont pour la plupart des corrections ou des optimisations, à tel point que le lot habituel de correction de bugs est réduit à la portion congrue.
En effet, seul quatre bugs ont été supprimés, correspondant aux identifiants #54367, #54585, #54623 et #54580.
La modification la plus significative concerne le support d'OpenSSL, qu'il devient possible d'intégrer à PHP lors de la sa compilation même si la version d'OpenSSL installée au niveau du système d'exploitation ne dispose pas de SSL version 2.
Cette version de SSL présente en effet un certain nombre de failles et n'est donc plus incluse systématiquement par les distributions telles que Debian.
Concernant internals@, Les discussions ont eu pour sujet principaux la suppression de l'erreur de type E_NOTICE
générée lorsque le développeur accède à une valeur indéfinie d'un tableau via l'opérateur ternaire, l'implémentation d'une fonction ou d'une construction du langage autorisant la définition d'une valeur par défaut si une variable n'est pas définie lorsque le développeur y accède, ainsi que sur la définition du type de la valeur de retour des fonctions ou des méthodes.
La discussion au sujet de la fonction varset()
, qui devait permettre de donner automatiquement une valeur à une variable indéfinie, a monopolisé l'attention pendant plusieurs jours, mais malheureusement, aucun consensus ne s'est dégagé du débat, malgré un grand nombre de propositions alternatives.
Il faut dire que le débat était double, puisqu'il rejoignait celui concernant l'opérateur ternaire débuté il y a maintenant pas mal de temps, et que cela n'a pas aidé pour avoir une discussion construite.
Donc pour l'instant, il n'y a aucune solution concernant la problématique posée par l'opérateur ternaire, et la proposition d'inclure varset()
au langage n'a pas été retenue.
Il en va de même pour la définition du type des valeurs de retour possibles pour une fonction ou une méthode.
Revenu à la surface suite à la proposition de sortir une nouvelle version de PHP basée sur le trunk, ce débat enflamme toujours autant les contributeurs, tout comme celui concernant le contrôle du type des arguments d'une fonction ou d'une méthode, revenu également à la surface par transitivité.
La majorité des développeurs sont en effet toujours en train de débattre pour définir si l'ajout de ces deux fonctionnalités a du sens par rapport à la gestion dynamique du type des variables effectuée par le langage.
En conséquence, il y a une totale absence de consensus à ce niveau, et il y a donc peu de chances que ces nouveautés
fassent parties de la version qui sera construite à partir du trunk.
Outre ces trois sujets, il a également été question sur internals@ du périmètre fonctionnel du serveur http qui doit être intégré à PHP à des fins de développement, notamment au niveau des possibilités de déboggage qu'il doit offrir, mais malgré cela, les choses semblent bien parties pour que ce serveur fasse effectivement parti du langage.
La question de l'utilisation d'un DCVS pour remplacer Subversion est également revenue sur le tapis, mais pour l'instant, rien de concret n'est sorti de la discussion, même si la levée de bouclier a été moins virulente que lors du dernier débat sur ce sujet, certainement parce que le sujet a été amené de manière extrêmement diplomatique.
Cette rétrospective est maintenant terminée, vous pouvez reprendre une activité normale.
29 réactions
1 De stealth35 - 02/05/2011, 23:55
De mon coté, j'ai fais quelques demandes de feature surtout coté session :
2 De desfrenes - 03/05/2011, 00:14
Dommage de restreindre le serveur "seulement" à des fins de développements. J'imagine que le voir autrement ce serait réouvrir la porte aux débats sur les threads...
3 De mageekguy - 03/05/2011, 00:17
@desfrenes : Indépendamment du problème des threads, qui n'en est d'ailleurs pas un vu que le serveur n'est pas écrit en PHP, un vrai serveur web n'a rien à faire au sein de PHP.
4 De mageekguy - 03/05/2011, 00:18
@stealth35 : Je ne veux pas doucher ton enthousiasme, mais vu que tout ce que tu proposes est faisable très facilement au niveau userland, il ne faut pas que tu ais beaucoup d'espoir de voir tes propositions acceptées (même si elles sont loin d'être stupides).
5 De desfrenes - 03/05/2011, 00:28
"un vrai serveur web n'a rien à faire au sein de PHP."
Des arguments s'il te plait.
6 De Julien Breux - 03/05/2011, 00:39
Un serveur HTTP dans PHP...
Depuis le temps qu'on râle pour avoir un DVCS digne de ce nom...
Merci, je retourne donc a une activité normal.
7 De stealth35 - 03/05/2011, 00:52
Ça viendra je suis patient, c'est jamais des gros trucs, c'est pour moi des
et pour l'instant, j'en ai eu quelques-un d’acceptés :SplFileObject::fputcsv()
,Transliterator
,RegexIterator::replace()
,FILTER_FLAG_EMPTY_STRING_NULL
.Et un direct refusé alors qu'il me semble légitime : #54091.
Et j’oubliais également le postfix du
RecursiveTreeIterator
(#54587) :).8 De mageekguy - 03/05/2011, 09:20
@desfrenes : Tu veux vraiment que je te réponde ?
PHP est un langage de programmation.
À partir de là, tout est dit, mais comme je pense que cette réponse ne te satisfera pas pleinement, je vais développer.
Tout d'abord, ce n'est pas parce que PHP sait dialoguer avec le Web qu'il doit intégrer un serveur Web digne des standards de production : fournir un environnement de production complet n'est nullement l'objectif du projet PHP.
Ensuite, si jamais ça l'était, développer un serveur web digne des standards de production est un boulot titanesque, il n'y a qu'à voir le temps de développement d'apache, nginx et autres pour s'en convaincre.
D'autant qu'il faudrait supporter http, https, l'authentification LDAP, kerberos, les rewrites rules, j'en passe et des meilleurs, pour répondre aux besoins du marché, bref, refaire le boulot effectué sur les serveurs web déjà existant.
Et franchement, les développeurs de PHP ont d'autres chats à fouetter, d'autant que cela supposerait bien évidemment d'en faire le support.
Autant avoir un serveur web suffisamment fiable dans un environnement de développement peut être intéressant, autant disposer nativement d'un équivalent à Lighthttp, Nginx, Apache ou autre est juste totalement inutile.
Il y a plusieurs solutions fiables et éprouvées sur le marché en ce qui concerne les serveurs web, à quoi bon donc réinventer la roue ou prendre du temps pour l'intégrer au langage ?
9 De desfrenes - 03/05/2011, 10:38
"Tu veux vraiment que je te réponde ?"
Non, pas du tout, j'écrivais ça pour perdre du temps...
Trêve de plaisanterie, je partage tout à fait ton avis sur le fait qu'un serveur web *dans* PHP serait assez inutile, surtout avec ces limitations, en revanche je pense qu'un serveur web *en* PHP serait utile, cf CherryPy pour un autre langage que j'affectionne. Il existe déjà, c'est Nanoweb, mais il commence à dater et n'est plus développé...
10 De mageekguy - 03/05/2011, 10:39
@desfrenes : En PHP ? Je suis un aficionados des trucs extrêmes, voir débiles, écrit en PHP, mais il y a des limites.
Quel est l'intérêt ?
11 De desfrenes - 03/05/2011, 10:47
Ouais nan, t'as raison, ça sert à rien en fait. PHP n'est pas un langage généraliste après tout. Il faut qu'il reste dans son champ d'action actuel, c'est très bien comme ça.
Ah, sinon impossible de te suivre sur Twitter... bug chez eux ou il y a une raison particulière ?
12 De usul_ - 03/05/2011, 10:55
Moi je dis ça, je dis rien mais mageekguy vient juste d'écrire : "à quoi bon donc réinventer la roue", comme quoi ... :D
13 De mageekguy - 03/05/2011, 11:15
@desfrenes : Aucune raison particulière de mon côté pour que tu ne puisses pas me suivre, donc j'incriminerais plutôt twitter.
Sinon, désolé, mais intégré un serveur http digne de la production dans PHP, même écrit en PHP, j'ai beau cherché, je n'en vois pas du tout l'intérêt, surtout depuis que le web est devenu un service critique qui doit être capable de tenir une charge conséquente.
Et PHP n'est pas taillé pour ce genre de boulot.
14 De mageekguy - 03/05/2011, 11:19
@usul_ : Quand la roue tourne et que c'est néfaste au bon fonctionnement du projet, la réinventer ne me gène absolument pas.
Mais si elle tourne rond, et qu'en plus elle n'est pas dans le périmètre fonctionnel du projet, je dis non.
15 De desfrenes - 03/05/2011, 11:51
Non mais faut pas être désolé... je me doute que ça ne peut pas intéresser tout le monde mais il y a forcément des cas d'utilisation. CherryPy est par exemple souvent utilisé en serveur d'application Python derrière un NGinx qui fait office de proxy. Dans ces cas là c'est toujours bon d'avoir une pile simplifié.
Le plus marquant quand même c'est d'en arriver à se dire "PHP n'est pas fait pour ça". PHP est parfois présenté comme un langage généraliste (pas forcément par toi), mais dans les faits ce n'est pas le cas. PHP n'est pas taillé pour ce genre de boulot, effectivement, mais ailleurs on ne se demande pas si c'est taillé pour: ça fonctionne.
J'ai un peu l'impression d'un projet qui se repose sur une énorme base installée mais qui ne va plus trop de l'avant, même si on peut reconnaitre des avancées avec la 5.3. Si je démarrais maintenant dans le métier tout ça ne m'exciterait pas beaucoup. L'innovation se fait souvent ailleurs (js, python, ruby,...) puis que les bonnes idées sont "back-portées" sous forme de librairies sous PHP, parfois en versions dégradées. ça crève les yeux dans le monde des frameworks (que tu affectionnent ;-)). Exemples: Django inspire Pluf, Jinja inspire Twig, Sinatra inspire NiceDog, Rails inspire Cake, etc.
Bref, l'impression que l'herbe est plus verte chez le voisin. Reste à oser sauter par-dessus la clôture.
16 De mageekguy - 03/05/2011, 12:14
@desfrenes : Je suis d'accord, l'innovation est un peu absente de PHP depuis quelques temps (mis à part les traits, il n'y a rien de bien novateur dans le trunk).
Mais a-t-elle été jamais présente ?
Pourrais-tu me citer une seule fonctionnalité spécifique/exclusive à PHP, ou bien qui a été reprise par un autre langage ?
De plus, il est difficile d'innover lorsque la base d'utilisateur est si importante, car pour innover, il faut parfois revoir en profondeur certaines choses et donc casser la compatibilité avec l'existant.
PHP 6 devait le faire, et nous savons tous ce qu'il s'est passé.
Je pense que cela a conforté les développeurs dans le fait que la prise de risque n'était pas forcément une option viable, malheureusement (ou pas).
17 De desfrenes - 03/05/2011, 21:51
Et allez... encore un exemple... http://www.fructoselang.org/
18 De mageekguy - 03/05/2011, 22:09
@desfrenes : Exemple de quoi ? de la bêtise humaine ?
19 De desfrenes - 03/05/2011, 22:49
Chacun prend son plaisir ou il veut... ça ou collectionner des timbres ou implémenter brainfuck... et puis je suis sur que ça lui est très utile à cette personne, c'est pas très charitable de le prendre pour un con juste parce qu'il a osé partager son truc.
Quelque part ce type a du se dire "j'aimerai bien faire du ruby mais je peux pas parce que telle ou telle raison alors je vais faire un ruby qui donne du php". Ce qui est important c'est qu'il a voulu faire ça et pas l'inverse. Je suis sur que tu vois où je veux en venir.
20 De Paul - 04/05/2011, 08:24
J'ai essayé le framework python Turbogears 2(http://turbogears.org).
Au début, ca m'a choqué que le serveur http soit intégré au framework.
Après utilisation, la seule bonne raison était pour le développement.
Car on a pas besoin de s'embêter à crée des vhosts/enregistrement DNS & co
(cf le billet de http://www.geek-directeur-technique...).
Mais pas pour de la production.
PS: comment on fait les sauts de lignes ?
21 De desfrenes - 04/05/2011, 10:25
J'ai demandé à l'auteur le pourquoi de fructoselang:
"hello !
I was curious to know how/why you started fructoselang, what was your motivation ? Is it out of a necessity or a pure intellectual exercise ?
see you."
réponse:
"I did Fructose for a couple of reasons. Mainly it was to understand
compilers at a high level, and second was to actually make something
useful.
Fructose is useful for the small niche of people who only have access
to PHP, but would like to use a nicer language."
Bêtise humaine ?
22 De Marc - 04/05/2011, 14:52
En même temps, s'il y a des projets qui se développent en ce sens, c'est surement qu'il y a une demande, ne serait-ce que par un soucis d'une meilleure portabilité de certaines applis (pas forcément orientées web d'ailleurs), non ?
23 De mageekguy - 04/05/2011, 14:57
Je ne suis absolument pas convaincu par les arguments donnés pour justifier l'existence de Fructose, exception faite de l'un de ceux de l'auteur, à savoir qu'il a fait cela pour apprendre (et pour le coup, j'avoue que l'idée est brillante).
Aujourd'hui, être limité par l'absence d'un langage est quand même tout de même très improbable, à part dans des structures très figées, et dans ce cas, utiliser une sur-couche de ce type est à mon sens casse-gueule, en raison (entre autre) des problèmes de compatibilité potentielle.
Donc dans ce contexte, je préconiserais de soit utiliser le langage disponible et de ne pas chercher à contourner le problème, soit de changer de société, avec une nette préférence pour la seconde solution.
24 De Amaury - 04/05/2011, 18:07
Quelques réactions dans le désordre, après avoir lu les commentaires.
Il est possible de faire un démon un PHP qui tienne la route même sur de grosses volumétrie. C'est ce que je fais avec FineFS (http://finefs.googlecode.com) et sur mes serveurs de production ça carbure, c'est stable (uptime qui se compte en mois et consommation mémoire qui n'augmente pas au fil du temps) et c'est plus léger en consommation CPU que ce à quoi je m'attendais. Donc techniquement, faire un serveur HTTP en PHP, c'est faisable.
D'ailleurs, si j'avais besoin de le faire, je le ferais en PHP. Le truc, c'est qu'effectivement, je n'ai pas ce besoin-là, et j'ai du mal à imaginer à quoi ça pourrait servir vu comment c'est facile de mettre en place un serveur Apache qui s'intègre parfaitement aux développements PHP (cf. mon billet cité par Paul).
Sinon, un projet comme Fructose ne me semble pas plus débile que tous les langages alternatifs basés sur la JVM, comme Scala qui est très à la mode en ce moment.
25 De mageekguy - 04/05/2011, 22:20
@Amaury : J'ai moi même des démons écrit en PHP, et pour certain, ils tournent depuis des années (le record est de plus de 641 jours) sans aucun problème.
Donc oui, c'est faisable de faire des démons en PHP, et c'est donc faisable d'écrire un serveur web en PHP.
Je n'ai d'ailleurs jamais mis cela en doute.
Par contre, je doute fortement qu'un tel serveur soit capable de tenir une charge significative correctement dans un cadre de production, et pour tout un tas de raisons.
Du coup, le concept perd fortement de son intérêt, qui n'était déjà pas bien grand au départ, du fait de la simplicité de mise en oeuvre de solution plus efficace et du nombre de ressources important que l'intégration d'un tel outil dans PHP demanderait aux contributeurs, alors que ce n'est clairement pas l'objectif du projet.
Quand à Fructose, j'ai peut être été trop vif dans mes propos et je me suis certainement mal exprimé.
J'admire la volonté et l'intelligence qu'il a fallu pour développer cet outil.
Cependant, je n'adhère pas à sa philosophie, car j'estime que remplacer Ruby par du code Ruby transformé en PHP est une mauvaise idée.
Le résultat sera au final plus mauvais que du code PHP
, et de plus, je pense que les concepts les plus intéressants de Ruby ne sont tout simplement pas transposable en PHP, puisque ce dernier ne dispose pas des primitives indispensables, sans compter qu'en plus, le débuggage doit être une horreur.Autant je peux comprendre la démarche de HipHop, qui apporte une réelle valeur ajoutée, sous la forme d'une amélioration des performances (aux prix de contraintes significatives comme par exemple l'utilisation d'une version de PHP < 5.3) , autant le bénéfice apporté par fructose ne me semble pas pertinent, voir même inexistant.
Bref, je pense que le jeu n'en vaut pas la chandelle fonctionnellement parlant, mais intellectuellement, c'est remarquable (si ça marche réellement, car je n'ai pas testé).
26 De desfrenes - 04/05/2011, 22:55
La moulinette tourne avec .Net 4.0 avec des dépendances qui font que tu as besoin de certaines dll même pour le compiler avec Mono... je suis pas près de pouvoir le tester non plus ^_^
27 De Paul - 05/05/2011, 15:26
Je vous avoue que je n'ai jamais rencontrer dans mon entreprise le besoin de faire un démon en PHP.
Y a t'il des spécificités propre à PHP pour écrire un démon ?
28 De mageekguy - 05/05/2011, 21:21
@Paul : Vu que l'on m'a posé plusieurs fois aujourd'hui des questions sur ce thème, je me suis fendu d'un billet.
29 De Paul - 06/05/2011, 06:58
Wouah merci, je n'en demandais pas tant