Dans le Premier Kata WordWrap, nous avons vu comment la technique d’appliquer le TDD en faisant des petits pas nous emmène à construire l’algorithme de façon simple et automatique. Nous allons voir un deuxième exemple de cette technique via un deuxième Kata, Le kata populaire Facteurs Premiers (PrimeFactors).

Dans ce Kata, nous verrons encore s’appliquer la prémisse de « Transformations » que nous rapporte Uncle Bob.

Prenez un peu de temps pour suivre les étapes du Kata et vous pourrez forker et utiliser le code depuis Github.

Enoncé du Kata

Ecrire une classe « PrimeFactors » qui a une seule méthode statique « generate ». Cette méthode prend un argument de type entier et retourne un tableau d’entiers représentant les facteurs premiers.

Implémentation

Commençons par créer un test PrimeFactorsTest vide

et s’assurer que notre PHPUnit nous affiche bien un warning qui ressemble a ceci :

la suite...

Cette RFC proposait d’ajouter une option (un flag) supplémentaire à json_encode().

Elle partait en effet du constat que json_encode() encode le flottant 10.0 (côté PHP) vers l’entier 10 (côté JSON). L’opération inverse JSON → PHP donnait donc l’entier 10 (côté PHP) — et, donc, encoder puis décoder une donnée ne menait pas à la même information que celle de départ.

// Actuellement
echo json_encode(10.0); // Affiche 10
echo json_encode(10.1); // Affiche 10.1
var_dump(json_decode(json_encode(10.0))); // Affiche int(10)
var_dump(10.0 === json_decode(json_encode(10.0))); // Affiche bool(false)

Par conséquent, il était proposé d’ajouter un nouveau flag JSON_PRESERVE_FRACTIONAL_PART qui entraînerait la conservation de cette information.

// Proposé
echo json_encode(10.0); // Affiche 10
echo json_encode(10.1); // Affiche 10.1
echo json_encode(10.0, JSON_PRESERVE_ZERO_FRACTION); // Affiche 10.0
echo json_encode(10.1, JSON_PRESERVE_ZERO_FRACTION); // Affiche 10.1
var_dump(json_decode(json_encode(10.0, JSON_PRESERVE_ZERO_FRACTION))); // Affiche double(10)
var_dump(10.0 === json_decode(json_encode(10.0, JSON_PRESERVE_ZERO_FRACTION))); // Affiche bool(true)

Note

Stocker 10.0 sous la forme 10 ou sous la forme 10.0 en JSON est conforme à la spécification JSON, qui ne différencie pas les différents types de nombres — et certains langages convertissent en 10.0 alors que d’autres, comme PHP aujourd’hui, convertissent vers 10.

• URL : https://wiki.php.net/rfc/json_preserve_fractional_part
• Version cible : PHP 5.x.x

Les votes ont été ouverts sur cette RFC le 11 janvier 2015 pour être clôturés le 18 janvier 2015 et nous avons exprimé un avis favorable sur internals@.
Cette proposition a été adoptée par 14 voix contre aucune.

L'AFUP est une association, et si elle parvient à organiser deux événements par an et représenter la communauté PHP à l'année, c'est notamment grâce à l'aide, financière ou matérielle, de ses sponsors.

Un grand merci à Gandi, fidèle partenaire de nos événements, qui soutient encore un peu plus notre démarche par cette action concrète ! 

Et pour rappel, le dossier de sponsoring pour le prochain PHP Tour Luxembourg 2015 est prêt : sponsors, contactez-nous pour le recevoir.

Lorsque Sass 3.4+ génère des feuilles de styles au charset UTF-8, il lui arrive parfois d’ajouter le BOM. Ceci afin de respecter la recommandation CSS Syntax Module Level 3.

Rien d’anormal ni de gênant, sauf si vos feuilles de styles sont concaténées par un outil qui ne vérifie pas la présence du fameux BOM pour le supprimer avant fusion des fichiers. En effet si un outil, tel que le minificateur de Drupal, conserve le BOM des fichiers, le fichier résultant contiendra des caractères cryptiques (les fameux ) situés à chaque début de ligne qui correspond au début du fichier concaténé.
Or, les navigateurs vont purement et simplement ignorer ces lignes.

C’est ainsi que hier, après activé la minification Drupal, que je me suis retrouvé avec un site dépourvu de ses webfonts. Webfonts qui n’étaient jamais téléchargées par le navigateur.

La solution la plus rapide à mettre en place dans mon cas de figure fut d’implémenter le callback on_stylesheet_saved mis à disposition par Compass afin de supprimer les fameux BOM des fichiers générés :

1
2
3
4
5
6
7
8
9
10
11
12

# config.rb
#
 
# Removes the BOM for UTF-8 stylesheets.
on_stylesheet_saved do |filename|
  css     = File.open(filename, 'r')
  content = css.read
  if "UTF-8" == content.encoding.name
    content.sub!("\xEF\xBB\xBF".force_encoding("UTF-8"), '')
    File.

la suite...

Voici une RFC qui avait été évoquée pendant les discussions à propos de UString : Using objects as keys.

L’idée de cette RFC était de permettre (de façon détournée) à des objets d’être utilisés comme clefs de tableaux — les tableaux PHP ne supportant en interne, comme clefs, que des entiers ou des chaînes.

Pour cela, une nouvelle méthode magique (qui pourrait être nommée __hash() — le nom proposé n’étant pas nécessairement définitif) serait mise en place : elle serait appelée lorsque l’on essayerait d’utiliser un objet comme clef d’un tableau, pour retourner la chaîne de caractères ou l’entier à réellement employer.

Par exemple, il deviendrait possible d’écrire quelque chose de ce type :

$obj = new MaClasse(); // implémentant une méthode __hash()
$arr = [];
$arr[$obj] = /* ici, quelque chose stocké dans le tableau, à l'index $obj->hash() */

• URL  :  https://wiki.php.net/rfc/objkey
• Version cible : PHP 7

Les votes se sont tenus entre le 16 décembre 2014 et le 6 janvier 2015 et requéraient une majorité de 2/3. Nous avons exprimé notre opinion, défavorable du fait que cette proposition n’aille pas assez loin, sur internals@.
Cette proposition a été rejetée à 24 voix contre 6.

Le but de la RFC PHP 5.7 était de créer la version susnommée afin de simplifier la transition vers la version 7 qui avait été actée.
Il était prévu pour cette version mineure de générer des avertissements E_DEPRECATED pour les fonctionnalités dépréciées ainsi que réserver des mots-clefs introduits par PHP 7. Celle-ci n’apporterait aucune nouvelle fonctionnalité.

Nous avons, pour la majorité, été convaincu par les deux principaux arguments de cette RFC :

• les applications pouvaient aisément résoudre les problèmes de compatibilité apportés par PHP 7 avant même que celle-ci soit officiellement disponible, accélérant ainsi son adoption
• l’ajout d’une année supplémentaire au support de PHP 5, qui se termine actuellement en août 2017, aurait permis d’assurer à la version PHP 5 des correctifs, notamment de sécurité, jusqu’en 2018.

Confrontée aux statistiques d’utilisations de PHP proposées par Pascal Martin, des arguments contraires se sont toutefois fait entendre à l’encontre de cette RFC. En effet, il apparaît que les deux versions PHP les plus utilisées aujourd’hui sont PHP 5.2 et PHP 5.3 ; l’ajout d’une version 5.7 n’aurait donc eu vraisemblablement que peu d’incidence sur l’adoption de PHP 7.

Nous avons donc donné un avis relativement partagé sur internals@, précisant que le plus important restait toutefois la sortie de PHP 7.

La RFC a été rejetée par 19 voix contre 14, car pour l’heure, PHP 7 n’intègre pas suffisamment de problèmes de rétrocompatibilité pour justifier une version 5.7.
Néanmoins, les échanges sur internals@ ont laissé entendre que si des RFC générant des problèmes majeurs de rétrocompatibilité venaient à être intégrées au périmètre de PHP 7, une RFC à propos de PHP 5.7 pourrait se voir offrir une seconde chance et un nouveau vote.

A l'heure où les banquiers doivent se poser la question de quitter le Luxembourg (affaire Luxleaks et Cie) et de s'intaller en Grèce (vu que la dette est LA priorité du nouveau gouvernement là-bas, j'imagine Alexis Tsipras annoncer que la finance est son ami incontournable), les développeurs PHP ont une occasion unique d'aller visiter du pays. Pour la première fois, le PHP Tour quitte le sol français et fera un détour en mai 2015 chez nos amis luxembourgeois.

D'ici les 12 et 13 mai 2015, il vous reste quelques temps pour proposer une conférence (ou deux) : le thème retenu pour cette année est PHP et le Cloud. L'appel à conférenciers est ouvert jusque fin février. En espérant que l'évènement soit à la hauteur du lieu, parce que le Centre Culturel de Rencontre Abbaye de Neumünster a l'air magnifique... Et qui sait, peut-être aurons-nous l'occasion de goûter au Judd mat Gaardebounen.

Cette RFC proposait de permettre l’utilisation de séquences Unicode dans les chaînes de caractères (à double-guillemets et heredoc) de PHP.

$str = "Un caractère unicode : \u{1F602}";

La RFC proposait d’autres exemples et expliquait pourquoi il avait été choisi de positionner { et } autour du code du caractère : lisibilité et pas de limite en dur au nombre de caractères attendus pour spécifier le code.

• Version cible : PHP 7
• URL de la RFC : https://wiki.php.net/rfc/unicode_escape

Les votes se sont tenus du 8 décembre 2014 au 18 décembre 2014 et nous avons exprimé notre opinion positive sur internals@.
La RFC a été adoptée à 23 voix contre 2.

Cette invitation, réservée aux représentants de communautés du numérique de France, est un marqueur de l'importance de PHP aujourd'hui, et de l'influence de l'AFUP et de sa communauté de développeurs.

Une bonne façon de commencer cette année 2015, célébrant les 15 ans de l'AFUP et les 20 ans de PHP !