PHP Java/Eclipse Page 2 PHP Page 8 Dev
Total Page：16
File Type：pdf, Size：1020Kb
DeveloppezLe Mag Edition de Octobre - Novembre 2009. Numéro 24. Magazine en ligne gratuit. Diffusion de copies conformes à l’original autorisée. Réalisation : Alexandre Pottiez Rédaction : la rédaction de Developpez Contact : [email protected] Sommaire Article PHP Java/Eclipse Page 2 PHP Page 8 Dev. Web Page 14 JavaScript Page 22 (X)HTML/CSS Page 28 SGBD Page 30 MS Office Page 36 Comment PHP a-t-il obtenu tant de C/C++/GTK/Qt Page 43 succès ? Mac Page 49 Conception Page 51 2D/3D/Jeux Page 56 Découvrez une interview de Rasmus Lerdorf réalisée par le Liens Page 64 magazine américain Linux Format. par La rédaction PHP Page 8 Article Développement Web Editorial Passez à l'UTF-8 sans La température baisse, mais chez Developpez.com on s'active manquer une étape d'autant plus pour vous fournir notre sélection de meilleurs articles, critiques de livres, et questions/réponses sur diverses Ce tutoriel va vous expliquer comment encoder votre site technologies. intégralement en UTF-8 sans louper une étape qui pourrait Profitez-en bien ! faire apparaître des caractères disgracieux. La rédaction par Josselin Willette Page 14 Java/Eclipse Blogs Java/Eclipse Projet Coin : Les modifications du type Generics, notamment car la vérification du typage n'est pas effectuée au même moment (à la compilation langage pour Java 7 pour les Generics, et à l'exécution pour les tableaux), ce qui peut entraîner des états totalement incohérents et Il y a quelques mois de cela naissait le projet Coin difficiles à résoudre... (Lien1), qui avait pour objectif d'étudier les différentes Toutefois, l'ellipse (également introduite dans Java 5) propositions d'évolution du langage pour leurs éventuelles utilise des tableaux en interne. De ce fait lorsqu'on utilise intégration dans la prochaine version de Java. les Generics avec l'ellipse, on peut se retrouver Le projet a eu un certain succès en recevant plus de 70 implicitement à créer des tableaux de types paramétrés : propositions, et c'est désormais l'heure du bilan : on connaît enfin la liste des changements acceptés pour Comparator<String> c1 = ... l'inclusion dans le JDK7 : Project Coin: The Final Five (Or Comparator<String> c2 = ... So) (Lien2). Comparator<String> c3 = ... List<Comparator<String>> list = On retrouve donc 7 propositions (dont deux en regroupent Arrays.asList(c1, c2, c3); // warning plusieurs) proposant des modifications plus ou moins complexes sur 7 thèmes : • Le compilateur produit alors un warning peu explicite pour La syntaxe en losange (Diamond syntax) prévenir du problème potentiel : • Simplified Varargs Method Invocation • Amélioration des valeurs numériques Main.java:14: warning: [unchecked] unchecked • Support syntaxique des Collections generic array creation • Switch sur des chaînes de caractères of type java.util.Comparator<java.lang.String>[] for varargs parameter • Gestion automatique des ressources (ARM) • Support de la JSR 292 dans le langage Mais le gros problème c'est qu'on ne peut rien faire contre ce warning (si ce n'est utiliser l'annotation Voyons ceci d'un peu plus près... @SuppressWarning), et que le problème potentiel tant décrié dépend uniquement du cas où l'implémentation de L'héritage de Java 5.0 la méthode modifierait son tableau contenant les varargs... Commençons donc par ce qui pourrait être considéré ce qui est fortement déconseillé ! comme des correctifs suite à l'intégration des Generics Le warning a donc été déplacé sur la définition de la dans Java 5.0. Les changements suivants sont en effet méthode et non pas lors de chacune de ses utilisations, afin destinés à combler quelques lourdeurs héritées de d'éviter de multiplier les warnings inutilement. l'intégration des Generics dans le langage : Le sucre syntaxique La syntaxe en losange (Diamond syntax) Passons désormais à ce que l'on pourrait appeler du sucre J'en ai déjà parlé (Lien3) il y a quelques jours : il s'agit tout syntaxique, c'est-à-dire de nouvelles syntaxes qui se simplement d'une syntaxe permettant d'éviter la contentent de générer un code similaire mais plus verbeux. duplication de la déclaration des types paramétrés, qui Mais cela n'en demeure pas pour autant inutile ! dans tous les cas doivent impérativement être identiques. Note : il s'agit ici de regroupement de plusieurs La syntaxe en losange consiste tout simplement à laisser le propositions, et de ce fait les spécifications exactes ne sont paramétrage vide (le compilateur se charge alors de le pas pas encore détaillées. Je présente ici les fonctionnalités déduire du contexte). qui devraient normalement être prises en compte. Ainsi, ceci : Amélioration des valeurs numériques Map<Integer, List<String>> map = new HashMap<Integer, List<String>>(); En plus de la forme décimale (par défaut), octale (avec le préfixe '0') ou hexadécimale (préfixe '0x'), il sera possible Pourra être remplacé par cela : d'utiliser directement une forme binaire avec le préfixe '0b' : Map<Integer, List<String>> map = new HashMap<>(); int value = 0b10000000; // 128 Simplified Varargs Method Invocation Soyons directs : cette modification risque de passer L'intérêt de cela étant bien sûr de simplifier les opérations inaperçue pour 99% des développeurs ! bit à bit sans avoir à convertir les valeurs numériques dans En effet on retrouve ici un problème assez obscur qui une autre base... interdit l'utilisation de tableaux de type paramétré : pour Il sera également possible d'utiliser le caractère underscore diverses raisons il est impossible de créer des tableaux de ('_') de manière totalement arbitraire entre deux chiffres de Numéro 24 – Octobre-Novembre 2009 Developpez Magazine est une publication de developpez.com Page 2 n'importe quelle valeurs numériques : String>({ "French" : "Français", double amount = 1_000_000_000.00; // 1 milliard "English" : "Anglais", int color = 0xff_ff_ff; // white "Spanish" : "Espagnol" int binary = 0b11_1110_1000; // 1000 en }); binaire Les nouvelles structures de contrôle Ceci n'aura bien sûr aucune incidence sur la valeur générée On dénombre également deux (plus ou moins) nouvelles à la compilation ! Le seul et unique but de cela est structures de contrôle, toujours dans un objectif de simplifier la lecture du nombre par le développeur. simplification du code. Support syntaxique des Collections Switch sur des chaînes de caractères L'intégration dans le langage se verra également améliorer Tout aussi bête que son nom l'indique, cette structure pour les Collections, avec notamment un accès indexé permettra donc d'utiliser des chaînes de caractères dans un pour les Lists et les Maps (respectivement avec un entier switch : et un type compatible). Par exemple on pourra utiliser quelque chose comme cela : String value = ... List<String> list = ... switch (value) { Map<String, Integer> map = ... case "azerty": doSomething(); String firstValue = list[0]; break; list[0] = "new-value"; case "qwerty": doAnotherThing(); Integer i = map[firstValue]; break; map[list[0]] = map["x"]; case "": // do nothing List<String> list = ... break; Map<String, Integer> map = ... default: doDefaultAction(); String firstValue = list.get(0); break; list.set(0, "new-value"); } map.get(firstValue); Bref cela permet d'éviter les fastidieuses successions de map.put( list.get(0), map.get("x")); if/else... A noter également la possibilité d'écrire des collections Gestion automatique des ressources (ARM) très simplement, à la manière des tableaux : Nous voici dans un domaine déjà bien plus intérressant : la gestion des ressources. Ceux qui ont l'habitude de suivre // Les Lists sont déclarés via des crochets : mes interventions sur les forums savent sûrement qu'on List<Integer> integers = [ 1, 2, 3, 4, 5, 6 ]; touche là à un sujet qui m'est important, et qui figure d'ailleurs dans la FAQ Java : Comment libérer proprement // Les Sets sont déclarés via des accolades : les ressources ? (Lien4) Set<Double> doubles = { 1.25, 2.50, 3.75, 5.00, Le problème vient donc des ressources "externes"(fichiers, 6.25, 7.50 }; sockets, resultset/statement/connexion JDBC, etc.), non- gérables par le garbage-collector, et qui doivent donc être // Les Map sont déclarés via des accolades, avec deux-points séparant la clef de la valeur : libérées manuellement et explicitement via un appel à la Map<String, String> strings = { méthode close(). Et pour faire cela efficacement on est "French" : "Français", obligé de passer par un bloc try/finally par ressource, ce "English" : "Anglais", qui alourdit considérablement le code. "Spanish" : "Espagnol" L'objectif d'ARM est de simplifier tout cela en gérant }; automatiquement et proprement la fermeture du flux via une nouvelle syntaxe : Les collections ainsi créées sont immuables, mais étant donné que toutes les collections peuvent s'initialiser à try ( /* declarations des ressources */ ) { partir des données d'une autre collection, on pourra écrire /* traitements sur les ressources */ quelque chose comme cela pour obtenir une instance } modifiable à souhait : La déclarations des ressources s'effectue à la suite du try, List<Integer> integers = new et la fermeture est implicite dès la fin du bloc LinkedList<Integer>([ 1, 2, 3, 4, 5, 6 ]); correspondant. Pour reprendre l'exemple de la FAQ : Set<Double> doubles = new HashSet<Double>({ 1.25, 2.50, 3.75, 5.00, 6.25, 7.50 }); public static void writeToFile(URL url, File file) throws IOException { Map<String, String> strings = new HashMap<String, // 1 - Création de la ressource (Fichier) Numéro 24 – Octobre-Novembre 2009 Developpez Magazine est une publication de developpez.com Page 3 FileOutputStream