planetePHP.fr
BastNic's Blog BastNic's Blog 2015-03-15T15:30:00+01:00

2015

Zéro billet en 2013, un en 2014, ce blog a beau avoir dépassé les dix ans, il n'en est pas moins complètement déserté.

Avant de vous parler de ce 2015 me réserve, rapide débrief de 2014 :

Mariage_-_Clare_et_Bastien.jpg

  • Claire et moi sommes maintenant mariés ! Tout a été super pour cette unique journée.
  • J'ai eu l'honneur d'être conférencier aux cycles de conférences PHP Tour, SudWeb, Forum PHP et Paris Web. Les quatre conférences que je suis assidument depuis si longtemps.
  • Après JoliCode en 2012, deuxième création d'entreprise avec Cap Collectif.
  • J'avais arrêté le sport en 2009 au moment de quitter Bordeaux pour monter sur Paris. Ma situation se stabilisant, j'ai enfin pu m'y remettre. Je me demande maintenant comment j'ai fait tout ce temps sans réelle dépense physique…

Et donc, pour cette année 2015 :

livre-dette-technique-bastien-jaillot.jpg

la suite...

PHP Internals en français PHP Internals en français 2015-03-12T08:46:35+01:00

RFC: Exceptions in the engine

La RFC: Exceptions in the engine visait à généraliser l’utilisation d’exceptions dans le moteur PHP ainsi qu’à transformer en exceptions la plupart des erreurs fatales, ce afin de laisser aux applications la possibilité de contrôler ces erreurs.

Cette RFC introduisait pour cela deux nouveaux types d’exceptions :

  • EngineException : type d’exception générique générée par le moteur PHP
  • ParseException : exception générée lorsque le code PHP ne peut être traité

À cela s’ajoute une classe de base, abstraite, BaseException, qui viendrait se mettre en place dans la hiérarchie des exceptions comme suit :

BaseException (abstract)
 +- EngineException
 +- ParseException
 +- Exception
     +- ErrorException
     +- RuntimeException
         +- ...
     +- ...

Les blocs attrapant les exceptions de type Exception n’attraperaient pas ces nouvelles exceptions, ne générant ainsi aucun effet de bord côté utilisateur.

Il est ressorti de nos échanges que nous étions en très large majorité en faveur de cette RFC et avons donc posté en ce sens sur internals@.

Avec 60 voix pour et seulement 2 contre, cette RFC a été accepté et sera mise en place dans la version 7 de PHP.

PHP Internals en français PHP Internals en français 2015-03-11T08:30:52+01:00

RFC: Remove PHP 4 Constructors

La RFC: Remove PHP 4 Constructors, comme son nom l’indique, visait à supprimer les constructeurs introduits dans la version 4 de PHP, où la méthode de construction des objets était appelée comme la classe elle-même :

class Filter
{
    // Constructor as introduced in PHP 4
    function filter() {}
}

Ce comportement, qui induit souvent en erreur les développeurs, est depuis longtemps vu par beaucoup comme indésirable. Néanmoins, sa suppression visant (initialement) la version 7 de PHP fut génératrice d’interrogations, notamment à cause de son utilisation récurrente dans les extensions PEAR ou même sur WordPress.

Ce sujet a également animé les débats sur internals@ et la RFC a évolué pour passer en deux phases :

  • PHP 7 : les anciens constructeurs génèreront un avertissement de type E_DEPRECATED
  • PHP 8 : suppression des anciens constructeurs qui deviendront alors de simples méthodes.

Suite à cette mise à jour, les derniers doutes furent levés et nous avons majoritairement approuvé cette RFC, postant dans ce sens sur internals@.

Avec 49 voix pour  et seulement 4 contre, la dernière version de la RFC a été acceptée, devenant la toute première RFC validée ayant comme version cible PHP 8 !

 

PHP Internals en français PHP Internals en français 2015-03-10T08:30:32+01:00

RFC: Expectations

Voici une RFC destinée à servir principalement en environnements de développement :

L’idée derrière cette RFC, basée sur la fonction assert(), est de permettre l’exécution de code de débogage, en développement uniquement. Cela permettrait à la fois d’identifier des problèmes (encore une fois, en environnements de développement) et de documenter le code. Plusieurs exemples illustrant les différents cas d’usage sont donnés dans la RFC.

En cas d’échec, la condition spécifiée en premier paramètre de assert() n’étant pas vraie, une exception de type AssertException (soit spécifiée en second paramètre, soit générée automatiquement) sera levée — passer par une exception plutôt qu’une erreur permettant d’obtenir plus facilement une stacktrace.

L’activation ou non des assertions serait paramétrée par le biais d’une directive .ini nommée zend.assertions, qui pourrait valoir :

  • 1 : pour générer et exécuter le code correspondant aux assertions : c’est la valeur qui sera généralement utilisée en environnement de développement
  • 0 : pour générer le code mais ne pas l’exécuter
  • -1 : pour ne pas du tout générer le code de l’assertion (coût nul, à utiliser en production)

L’API proposée par cette RFC est globalement compatible avec celle actuellement en place pour la fonction assert() existante : il s’agit surtout d’améliorer celle-ci, notamment en supprimant complétement la génération et l’exécution du code de l’assertion en mode « production ».

Les votes se sont tenus du 19 au 26 février et nous avons exprimé un avis plutôt négatif sur internals@, considérant principalement que mélanger le code et les tests n’était pas l’approche qui nous semblait la meilleure et ne souhaitant donc pas encourager l’utilisation de assert().
Les résultats ont finalement été les suivants, cette RFC est donc passée :

  • 20 « oui » avec exceptions personnalisées
  • 11 « oui » sans exception personnalisée
  • 1 seul et unique « non »
AFUP AFUP 2015-03-06T00:00:00+01:00

L'AFUP soutient les Drupal Developer Days

L’association Drupal France & Francophonie organise, du 13 au 19 avril prochains, les Drupal Developer Days. Événement itinérant en Europe, c'est la première fois que l'event s'arrête en France, pour une semaine d'ateliers, de travail collaboratif, et de conférences organisés pour la communauté internationale des développeurs Drupal.

La semaine se déroulera en deux temps :  
- en fil rouge de cette semaine, seront organisés des ateliers de travail, autrement appelés “Sprints”, et des ateliers de discussions informelles, ou “BoF” (pour Birds of a Feather).
- les jeudi, vendredi et samedi seront les trois jours de temps forts de cette édition, pendant lesquels des conférences seront présentées.

Les objectifs de cette manifestation sont multiples : offrir un lieu de rencontre à la communauté Drupal internationale grandissante, apporter support et nouveauté aux développeurs spécialisés, faire progresser le logiciel alors que sa nouvelle version (la version 8) est très prochainement attendue et en voie de finition.

Les Drupal Dev Days s’ouvrent à tous les niveaux et à tous les univers. La communauté s’organise autour de cet événement et tous les développeurs souhaitant participer à l’amélioration de ce logiciel libre sont les bienvenus. En suivant le principe du mentorat, les nouveaux venus seront accompagnés dans cette semaine initiatique.  
Vous êtes curieux(se) de découvrir Drupal 8 ? plutôt intéressé(e) par la mise en forme ? les retours d’expérience ? les configurations avancées ? ou les techniques de développement ? Découvrez leur programme

Bonne semaine à la communauté Drupal !

PHP Internals en français PHP Internals en français 2015-03-05T08:30:16+01:00

RFC: Add pecl_http to core

La RFC: Add pecl_http to core avait pour objectif d’intégrer nativement à PHP 7 l’extension pecl_http. Cette extension permet de gérer des communications HTTP grâce à une implémentation orientée objet.

Néanmoins, la présence de curl permettant l’accès à la couche HTTP à bas-niveau ainsi que l’existence de bibliothèques comme Guzzle  apportant une implémentation orientée objet (en espace utilisateur, donc non liée au cycle de versions et de maintenance de PHP) nous a paru suffisant en l’état. De plus, l’extension pecl_http embarquait des dépendances qui seraient venues s’ajouter au cycle de maintenance de PHP. Nous avons donc posté en ce sens sur internals@.

Avec 9 voix pour et 23 voix contre, cette RFC a finalement été refusée : l’extension pecl_http restera disponible depuis PECL pour les intéressés, et ne sera pas distribuée avec PHP.

AFUP AFUP 2015-03-05T00:00:00+01:00

L'AFUP Toulouse vous présente Blackfire.io le temps d'un apéro

Il est désormais démontré que le temps de réponse de vos applications a un réel impact sur l’activité économique (taux d’abandon de commande, taux de rebond…). Dès lors, mesurer les performances de votre application n’est plus une bonne pratique, mais une nécessité pour la bonne santé de vos projets.
Venez découvrir comment l’outil Blackfire.io peut vous permettre de mesurer les performances de votre application, y compris en production et permettre d’augmenter sa qualité !

L'apéro PHP permettra de discuter autour de ce sujet, dans une ambiance conviviale. Les apéros PHP sont aussi l'occasion de faire connaissance avec les développeurs de la communauté PHP locale, d'échanger sur les pratiques de chacun et de bénéficier de l'expérience de la communauté.

Rendez-vous mardi 10 mars, à 19h, chez Etincelle Coworking (2 rue d'Austerlitz, Toulouse). Réservez votre place sur leur site, annoncez votre venue sur le site des aperos PHP.
Une bonne soirée à toute la communauté toulousaine !  

PHP Internals en français PHP Internals en français 2015-03-04T08:30:29+01:00

RFC: Group Use Declarations

Voici une RFC qui proposait d’ajouter une possibilité syntaxique à PHP, visant à faciliter l’utilisation d’espaces de noms : Group Use Declarations

Pour résumer, cette RFC partait du constat qu’écrire de multiples utilisations d’espaces de noms à plusieurs niveaux de profondeur entraîne une longueur de code impressionnante. Elle proposait donc l’introduction d’une nouvelle syntaxe, qui permettrait de réduire l’espace utilisé par ces use multiples et de rendre le code moins verbeux.

Par exemple, la portion de code suivante :

use Doctrine\Common\Collections\Expr\Comparison;
use Doctrine\Common\Collections\Expr\Value;
use Doctrine\Common\Collections\Expr\CompositeExpression;

Pourrait être ré-écrite de la manière suivante :

use Doctrine\Common\Collections\Expr\{ Comparison, Value, CompositeExpression };

La RFC présente d’autres cas d’exemples, avec des « use ... as ...« , des use function ou const et montre que la syntaxe n’est pas limitée au dernier niveau de chaque espace de noms. Elle répond également à certains retours « communs » sur la proposition et sa syntaxe.

Les votes ont été ouverts le 11 février 2015 et pour être clôturés le 25 février, avec deux options :

  • « Oui », avec un \ à la fin de l’inclusion (le dernier : dans l’exemple reproduit plus haut ...\Expr\{} ),
  • « Oui », sans cet \ à la fin de l’inclusion — on aurait donc ...\Expr{}
  • Et, bien sûr, « non »

Les discussions que nous avons menées sur notre mailing-list ne nous ont pas permis d’atteindre un consensus et nous avons exprimé sur internals@ les principaux arguments auxquels nous étions arrivés.

Une majorité de 2/3 était requise pour son adoption, et cette RFC a été approuvée avec les résultats suivants :

  • Oui, avec un \ à la fin de l’inclusion : 32 voix;
  • Oui, sans le \ à la fin de l’inclusion : 7 voix;
  • Non : 19 voix
PHP Internals en français PHP Internals en français 2015-03-03T08:30:07+01:00

RFC: Remove the date.timezone warning

La RFC Remove the date.timezone warning partait du constat qu’il existe à l’heure actuelle une directive de configuration qui nécessite d’être définie afin de pouvoir lancer PHP sans erreur : date.timezone.

Lorsque cette directive n’est pas configurée, une erreur de type warning est générée par PHP, même si le moteur lui attribue une valeur par défaut (UTC).

Le but de cette RFC était de supprimer cette erreur, afin de pouvoir fournir à PHP une installation paramétrée complète par défaut. En effet, il apparaît que de nombreuses autres directives, bien plus sensibles notamment en terme de sécurité, sont d’ores et déjà configurées par défaut.

Il nous semblait que l’absence de configuration de cette directive devait à minima générer une erreur stricte, car elle impacte des fonctions de date très usitées (telle date()), d’autant que la zone par défaut est aujourd’hui définie de manière arbitraire. Nous avons donc répondu en ce sens sur internals@.

Néanmoins, avec 32 votes pour et 11 contre, cette RFC est passée et l’avertissement correspondant ne sera donc plus levé à partir de PHP 7.

Pascal Martin (n+1).zéro Pascal Martin (n+1).zéro 2015-03-03T00:00:00+01:00

PHP 7 et processus d'évolution de PHP : slides de ma présentation à l'AperoPHP lyonnais du 25 février

Toutes les fin de mois1, l’antenne lyonnaise de l’AFUP organise un ApéroPHP :

Les apéros PHP sont ouverts à tous, quelque soit le niveau, le but est de rencontrer d’autres développeurs PHP de la région lyonnaise,
de boire un verre ensemble, de discuter de tout et de rien, en fonction des envies de tout le monde.

Lors de l’Apéro du 25 février 2015, j’ai eu l’occasion de donner une présentation, où j’ai parlé des nouveautés apportées par PHP 7, la prochaine version majeure de notre langage de prédilection, ainsi que du processus d’évolution de PHP, notamment à travers la mailing-list internals@.

Les slides que j’ai utilisés comme support sont disponibles en ligne2 : PHP 7 et processus d’évolution de PHP : slides de ma présentation à l’AperoPHP lyonnais du 25 février.



  1. En théorie, les ApéroPHP lyonnais ont lieu le 29 de chaque mois. En pratique, la date varie un peu, mais c’est généralement vers la fin du mois. Rendez-vous sur aperophp.net, ou suivez l’AFUP Lyon sur Twitter : @AFUP_lyon

  2. Pour ceux qui voudraient plus d’informations que les slides en eux-même, j’ai noté quelques points dans les notes du présentateur, accessibles via la touche s


Flux ATOM

Flux RSS
Twitter

Les sources

Ajouter une source ?

Envoyez un email avec l'URL du site et du flux à planetephpfr AT afup POINT org

Infos