Journal Java 7 est dispo !

Posté par snt le 28 juillet 2011 à 20:28. Licence CC By‑SA.

Étiquettes :

juil.

2011

Pour les développeurs de projets Entreprise, aujourd'hui est un grand jour. En effet Java 7 est disponible pour tous.
Seulement 5 ans après la sortie de Java 6 (décembre 2005), le langage Java propose une nouvelle évolution majeure pour rester compétitif. On retrouve ainsi :

L'inférence de type des variables
Les arguments optionnels
Les arguments nommés
Les méthodes d'extension
Les lambdas
Les arbres d'expression
Un langage de requêtage intégré
Le safe navigation operator
Les références non nulles
J'en passe et des meilleures

Euh. Ah non rien de tout ça.
Par contre, on peut désormais faire des switchs avec des chaînes de caractère. Whoaaaaa. Ils ont pas chômé les types de chez Sun^WOracle !

# 5ans 1/2 en fait

Posté par NeoX le 28 juillet 2011 à 20:43. Évalué à -1.

decembre 2005 - juillet 2011 ca fait pas 5 ans, mais 5 ans 1/2

bon, finalement c'est peut-etre ca leur probleme, sortir une version majeure à la veille des vacances alors qu'ils avaient 5 ans pour faire les choses bien :p
# Super journal

Posté par Laurent A. le 28 juillet 2011 à 21:26. Évalué à -8.

Franchement bravo pour ce journal car après le journal bookmark, voici le journal inutile. Je n'ai à peu près rien compris ou très vaguement à tout ce que tu as écrit. Par exemple «requetage», c'est quoi ?! Des références non-nulles ? Euh... c'est-à-dire ?!

Au moins, t'aurais pu mettre l'URL de l'annonce de la sortie : http://blogs.oracle.com/javase/entry/java_7_has_released (si c'est celle-là que tu avais lue).
- [^] # Re: Super journal
  
  Posté par Lebas Sébastien le 28 juillet 2011 à 21:32. Évalué à 10.
  
  Je pense que lire le dernier paragraphe du journal permet de comprendre pourquoi ces descriptions sont très floues ...
- [^] # Re: Super journal
  
  Posté par patapon le 29 juillet 2011 à 00:38. Évalué à 4.
  
  Et l'ironie dans l'histoire, c'est que nombre des évolutions existent en C# depuis un petit moment maintenant : les 7 premières c'est certain, le "safe navigation operator" non mais il est possible de le simuler avec une méthode d'extension (plus verbeux qu'un opérateur, moins que des ifs), et quant aux références non nulles, j'en sais rien.
  
  Il y aura toujours des mauvaises langues pour dire que ça sert à rien ou que MS n'a rien inventé, mais la réalité, c'est que c'est loin d'être du superflu.
  
  Pendant ce temps, chez SUN, on passe son temps à se chamailler sur la meilleure manière de spécifier les closures, pour au final rien produire.
  - [^] # Re: Super journal
    
    Posté par barmic le 29 juillet 2011 à 23:39. Évalué à -1.
    
    Quel est le rapport entre son commentaire et le tiens ?
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    - [^] # Re: Super journal
      
      Posté par patapon le 01 août 2011 à 11:29. Évalué à 1.
      
      Je crois que le rapport, c'est le manque de nouveautés liés à la sortie de Java 7. Il me semble même que c'est le thème du journal. Mais si mon commentaire ne te semble pas pertinent, libre à toi de le moinsser : il y a une fonctionnalité faite pour ça. Inutile de perdre ton temps à écrire ce genre de commentaire.
      - [^] # Re: Super journal
        
        Posté par barmic le 01 août 2011 à 19:58. Évalué à 1.
        
        Inutile de perdre ton temps à écrire ce genre de commentaire.
        
        Désolé de chercher à discuter. En fait, je vois pas vraiment l'intérêt de dire simplement qu'il n'a pas les même fonctionnalités qu'un autre langage. Je peux très bien dire que Java et C# n'ont pas de dynamicité par exemple dans un journal sur la prochaine version de JSE ou de .Net.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Super journal
        
        Posté par patapon le 03 août 2011 à 10:03. Évalué à -1.
        
        Tu n'as pas à t'excuser, vu que tu ne cherchais pas à discuter. Quand je cherche à discuter, je commence par éviter d’agresser mon interlocuteur en lui balançant un "C'est quoi le rapport ?". Mais peut être que je manque de savoir-vivre. Enfin, tu constateras par toi même lequel de mon commentaire et du tien n'avait aucun rapport le contenu du journal. Et je le redis : inutile de perdre ton temps à écrire ce genre de commentaire. Si mon post ne te plais pas, moinsse le et puis basta.
        
        Ceci dit, je vais quand même t'exposer mon point de vue. Le contenu du journal fait plus ou moins explicitement une comparaison avec C#. Le simple fait d'utiliser le terme 'labmda' au lieu et place de 'closures' le prouve (et inutile de me prendre pour un neuneu, je sais que ce n'est pas la même chose), sans parler des expressions tree ou de Linq. Pour ceux qui n'ont pas touché à ce langage développé par le vilain méchant MS, mon commentaire permet de relativiser la situation de Java, qui n'a pas évolué depuis un petit bout de temps (on parle ici du langage, pas de JEE) là où la concurrence a pris une avance significative..
        
        Car c'est bien le point essentiel : les deux langages sont en concurrence. Java et C# visent le même cœur de métier : les applications d'entreprise. Cela n'exclut pas les autres types d'applications, mais c'est là ou se fait le "business" pour ces langages. Il n'est pas ici question de comparer deux langages se basant sur des paradigmes différents (ASM et OCaml par exemple) ou deux langages ciblant des types d'applications différents. A partir de là, il me semble pertinent de comparer l’évolution de ces deux langages. Et il faut croire que je ne suis pas le seul, vu que snt le fait aussi.
        
        [^] # Re: Super journal
        
        Posté par barmic le 03 août 2011 à 11:55. Évalué à 1.
        
        Tu n'as pas à t'excuser, vu que tu ne cherchais pas à discuter. Quand je cherche à discuter, je commence par éviter d’agresser mon interlocuteur en lui balançant un "C'est quoi le rapport ?". Mais peut être que je manque de savoir-vivre. Enfin, tu constateras par toi même lequel de mon commentaire et du tien n'avait aucun rapport le contenu du journal. Et je le redis : inutile de perdre ton temps à écrire ce genre de commentaire.
        
        Oulala, la prochaine fois je ferrais gaffe à te prendre avec des pincette si j'y pense : « Excusez-moi, mais sans vouloir vous vexer, je ne comprends pas le liens entre votre commentaire et le journal. Pourriez-vous m'expliquer ce lien ? »
        
        Parce que C# désolé, je connais un peu mais je ne connaissais pas ces fonctionnalités (et d'après les autres commentaires de ce journal je ne suis pas le seul). Je suis d'accord avec le lien que tu donne sauf pour le mot clef « lambda » est utilisé dans d'autres langages par exemple python et que c'est même un vrai concept mathématiques puisque c'est le nom d'un modèle de calcul (oui ce n'est pas méchant envers C# d'expliquer qu'ils ne sont pas les seuls à utiliser ce mot).
        
        Si mon post ne te plais pas, moinsse le et puis basta.
        
        Ce n'est pas qu'il ne me plaît pas c'est que je ne l'ai pas compris. Je me sert de la fonction de vote au moins autant que toi, c'est bon j'ai compris comment ça fonctionne, mais quand je veux des précisions, je le demande (et franchement ta susceptibilité, je m'en fiche).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: Super journal
  
  Posté par patapon le 29 juillet 2011 à 00:48. Évalué à 3.
  
  Ah, quelques infos quand même:
  - Par langage de requêtage, je pense qu'il parlait d'un truc similaire à linq. En abrégé, ça permet de faire des requêtes "à la SQL" sur les collections (tableaux, listes, énumérations...). Je trouva la syntaxe de base moche, mais utilisé avec des lambdas, j'apprécie beaucoup.
  - Pour les références non nulles, je pense qu'il s'agit de références auxquelles on ne peut affecter la valeur null.
# Les vrais ajouts

Posté par barmic le 28 juillet 2011 à 22:25. Évalué à 10.
Java SE (parce que JEE n'évolue pas en même temps donc parler des entreprises...) 7 apporte :
- les switch sur les String (pratique mais pas fondamentale)
- les constantes entières séparées par des "_"
```
int val = 10_000_000;
```
- la classe Objects qui contiens quelques fonctions statiques pour notamment gérer de manière plus pratique les valeurs null
- une nouvelle API pour la gestion des entrées/sorties avec par exemple la possibilité de surveiller le système de fichier (en standard donc portable)
- une nouvelle version de la Javadoc avec aspect visuel plus intéressant
- le « diamond » qui permet d'utiliser les génériques de manière plus concise
```
List<String> l = new ArrayLst<>();
```
- les try-with-resources (je crois que ça existe déjà en python) :
```
try (BufferedReader br = new BufferedReader(new FileReader(path)) {
    return br.readLine();
}
```
- encore quelques ajouts (pour gérer les langages dynamiques et le multitâche notamment)
On peut trouver un article facile à lire sur développez.com :
Java 7 Release Candidate est disponible : retour sur nio2, coin, javadoc et ses autres nouveautés

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: Les vrais ajouts
  
  Posté par ckyl le 28 juillet 2011 à 22:39. Évalué à 4.
  
  Tu arrives donc au même constat que le journal ;)
  
  Java 7 c'est un epic fail. Le seul bon côté c'est que Oracle a débloqué la machine à release en décidant de livrer la 7 avec "rien" dedans plutôt que de reporter encore d'une année pour attendre les autres JSR.
  
  Mais ce que je préfère c'est qu'ils ont quand même réussi à pousser des changements qui pètent la compat dans JAXP. Enjoy :p
  - [^] # Re: Les vrais ajouts
    
    Posté par pasScott pasForstall le 28 juillet 2011 à 23:02. Évalué à 3.
    
    L'idee c'etait apparement de debloquer la machine a decision java en foutant un gros coup de pied dans la fourmilliere.
    Facon oracle, évidemment, d'ou les légers accrocs avec Apache et tout le cirque autour de hudson.
    
    En gros ils posent leurs couilles sur la table en disant "vous allez vous aimer maintenant, bordel de merde?!?"
    
    Maintenant, ils peuvent commencer a vraiment bosser :)
    
    La prochaine étape, c'est un cycle de release a la mozilla, avec une nouvelle version de la jvm qui pete tout tous les 3 mois.
    
    If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
    - [^] # Re: Les vrais ajouts
      
      Posté par ckyl le 28 juillet 2011 à 23:14. Évalué à 7.
      
      Apache et Hudson ce sont des autres problèmes qui n'ont rien a voir avec le retard de Java 7. Apache a essayé d'exploiter le vote sur Java 7 qui devenait urgent pour son baroud d'honneur; mais c'était purement politique. Hudson c'est juste un projet tiers qui n'a rien a voir dans le schmilbick.
      
      Après Oracle reste Oracle...
      - [^] # Re: Les vrais ajouts
        
        Posté par pasScott pasForstall le 28 juillet 2011 à 23:29. Évalué à 0.
        
        Je sais bien, c'était juste un mot d'humour.
        
        Apache est représentatif du bordel au JCP, c'est pas comme si sun allait super bien depuis 2006/7.
        
        Hudson est representatif de la claque que c'est prit oracle quand ils ont rencontre le monde de l'open source ou Larry ne peut pas être un dictateur qui tape du poing sur la table.
        
        Maintenant que le process commence a se débloquer, le vrai travail sur l'évolution de java peut reprendre pour de bon, c'était surtout ça l'objectif de cette release, bouger un peu histoire de sortir le langage de son apathie et le dynamiser un peu.
        
        If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
    - [^] # Re: Les vrais ajouts
      
      Posté par Antoine le 29 juillet 2011 à 00:22. Évalué à 10.
      
      Maintenant, ils peuvent commencer a vraiment bosser :)
      
      Avec ce qu'ils ont sur la table, ce n'est pas très pratique, si ?
      - [^] # Re: Les vrais ajouts
        
        Posté par pasScott pasForstall le 29 juillet 2011 à 01:04. Évalué à -2.
        
        Ah bah ca detend l'atmosphere, tout d'un coup.
        :)
        
        If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
      - [^] # Re: Les vrais ajouts
        
        Posté par Maclag le 29 juillet 2011 à 02:09. Évalué à 10.
        
        Ben c'est surtout que ça peut faire très mal si quelqu'un d'autre décide aussi de taper du poing sur la table...
- [^] # Re: Les vrais ajouts
  
  Posté par CrEv (site web personnel) le 29 juillet 2011 à 07:23. Évalué à 2.
  
  les switch sur les String (pratique mais pas fondamentale)
  
  C'est peut-être pas fondamental mais démontre juste le retard qui existe chez Java (ok, plus sur ce point) et surtout le côté bas niveau du langage.
  Et le switch c'est plus que pratique et beaucoup plus propre si tu as plus que 3 strings. Ne pas le gérer c'est assez difficilement justifiable.
  
  Pour le reste, ce que j'adore c'est que je connais des dev java qui disent que diamond n'est pas une bonne idée. Idem pour le resources.
  
  Il y a 3 améliorations et elles ne font même pas l'unanimité. Qu'est ce que ça aurait donné s'ils avaient réellement bossé pendant ces années !
  - [^] # Re: Les vrais ajouts
    
    Posté par devnewton 🍺 (site web personnel) le 29 juillet 2011 à 10:24. Évalué à 4.
    
    surtout le côté bas niveau du langage
    
    C'est aussi l'une des raisons de son succès...
    
    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
    - [^] # Re: Les vrais ajouts
      
      Posté par CrEv (site web personnel) le 29 juillet 2011 à 11:04. Évalué à -2.
      
      Et c'est surtout ce qui fait de java un langage in-intéressant (j'ai pas dis inutile)
      - [^] # Re: Les vrais ajouts
        
        Posté par CrEv (site web personnel) le 29 juillet 2011 à 15:49. Évalué à 2.
        
        Quelqu'un peut-il alors m'expliquer en quoi le côté bas niveau de java est intéressant et en fait son succès ?
        Par extension on pourrait alors dire que si java était un langage de plus haut niveau (par exemple en masquant les types primitifs) il n'aurait pas eu ce succès ?
        
        [^] # Re: Les vrais ajouts
        
        Posté par devnewton 🍺 (site web personnel) le 29 juillet 2011 à 16:33. Évalué à 3.
        
        Je pense que par "bas niveau", on a voulu dire qui n'a pas des millions de fritures comme [insérer ici un langage plus puissant]. En fait il y a peu de langages simples avec un typage statique...
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
  - [^] # Re: Les vrais ajouts
    
    Posté par claudex le 29 juillet 2011 à 10:46. Évalué à 4.
    
    Et le switch c'est plus que pratique et beaucoup plus propre si tu as plus que 3 strings.
    
    Le mieux, ce serait qu'il y a une instruction similaire au switch qui utilise la méthode equals, ça permettrait de le faire avec n'importe quel objet. Je parle d'une instruction similaire parce que je pense que ça tuerait les performances si on remplaçait les switch avec les types primitifs par de l'autoboxing et la méthode equals.
    
    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
    - [^] # Re: Les vrais ajouts
      
      Posté par CrEv (site web personnel) le 29 juillet 2011 à 11:31. Évalué à 10.
      Le mieux serait surtout de virer ce putain d'equals et de surcharger =
      
      Par certains côtés, java c'est comme gnome, on t'explique que certaines choses sont inutiles. Dans Gnome c'est pouvoir éteindre ton pc, dans java c'est surcharger == dans le but d'avoir des lignes de code logique.
      
      Franchement, sur ce point, quel est l'usage le plus courant :
      
      une égalité entre deux strings (égalité de référence) (==)
      
      une égalité entre deux valeurs (equals)
      
      Quel est la syntaxe la plus logique pour tester l'égalité entre deux chaînes de caractères ?
      
      equals
      
      ==
      
      Trouver la logique parmi les expressions suivantes :
      
      System.out.println("plop" == "plop" ? "true" : "false"); // true String a = "plop"; String b = "plop"; System.out.println(a == b ? "true" : "false"); // true String aa = "plop"; String bb = ""; bb += "plop"; System.out.println(aa == bb ? "true" : "false"); // false String aaa = "plop"; String bbb; bbb = "plop"; System.out.println(aaa == bbb ? "true" : "false"); // true System.out.println("plop".equals("plop") ? "true" : "false"); // true System.out.println(new String("plop") == new String("plop") ? "true" : "false"); // false System.out.println(new String("plop").equals(new String("plop")) ? "true" : "false"); // true
      
      ~~Autant Java a plein d'avantages~~
      Autant la jvm a plein d'avantages, autant java est pour moi un très mauvais langage.
      - [^] # Re: Les vrais ajouts
        
        Posté par ckyl le 29 juillet 2011 à 11:43. Évalué à 1.
        
        Java ne veut pas péter la compatibilité. Tu parles donc dans le vide et perd simplement ton temps ;)
        
        Les autres langages au dessus de la JVM combleront peut être tes attentes tout en pouvant tirer parti des API de Java.
        
        [^] # Re: Les vrais ajouts
        
        Posté par Gniarf le 29 juillet 2011 à 13:28. Évalué à 4.
        
        Java ne veut pas péter la compatibilité
        
        quand je vois passer des -Djava.util.Arrays.useLegacyMergeSort=true
        
        je me dis que c'est ratai.
        
        [^] # Re: Les vrais ajouts
        
        Posté par ckyl le 29 juillet 2011 à 14:21. Évalué à 8.
        
        Quand tu maintiens une compat sur 15+ ans sur un langage et une API aussi vaste il y a toujours quelques ratés (qui sont relou on est d'accord). Mais Sun s'en sort plutôt bien à ce jeux.
        
        Pour le point précis dont tu parles c'est toujours un problème pour les mainteneurs. Le code existant autorisait des conditions plus souples que ce que disait la spécification. C'est à dire que du code pourri était accepté. Du coup c'est le bordel quand tu veux mettre à jour:
        - Tu te dis que l'ancien comportement doit être gravé dans la pierre même si la spec dit que le code n'aurait jamais du marcher. C'est le mieux pour la compat mais au bout de 10 ans tu peux plus rien faire bouger (note que la spec n'a pas changé)
        - Tu te dis que la spec est bonne et reste intacte. Tant pis pour les mauvais utilisateurs ils fixeront leur code.
        - Tu te dis les deux et tu permets aux mauvais utilisateurs d'avoir une solution temporaire au cas où (solution retenue)
        - Tu introduis une nouvelle API. Il faudra migrer le code de toutes les applis pour tirer parti des optimisations et l'ancienne API doublon restera ad vitam eternam.
        
        Faire le choix entre ces solutions n'est pas évident et celle retenu n'est pas stupide. C'est exactement comme un compilo C qui était plus souple que la norme et un jour devient plus strict. Tu gardes la spec, la nouvelle implémentation a un bon comportement et tu permets aux mauvais élèves de continuer à compiler pendant quelques temps.
        
        Ca n’empêche pas qu'il y a quelques vrais problèmes ;)
        
        [^] # Re: Les vrais ajouts
        
        Posté par zebra3 le 29 juillet 2011 à 15:58. Évalué à 2.
        
        Quand tu maintiens une compat sur 15+ ans sur un langage et une API aussi vaste il y a toujours quelques ratés (qui sont relou on est d'accord). Mais Sun s'en sort plutôt bien à ce jeux.
        
        Permets-moi d'en douter. Je ne compte plus les applis qui demandent exclusivement la JVM 1.4 ou 1.5 (voire même la 1.3). Bien sûr, ce sont des applis utilisées en milieu pro.
        
        Je pense que si Sun avait réellement cherché à garder une compatibilité parfaite, il n'aurait pas laissé la possibilité d'installer plusieurs JVM en parallèle sur Windows.
        
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: Les vrais ajouts
        
        Posté par ckyl le 29 juillet 2011 à 16:13. Évalué à 9.
        
        Il y a plusieurs choses immuables en informatique:
        
        Les développeurs arriveront toujours à faire de la merde. Ça inclus plein de choses allant du code qui repose sur un effet de bord d'une implémentation au mec qui va taper directement les classes internes d'un JRE.
        
        Maintenir une compatibilité PARFAITE sur quelque chose de conséquent qui évolue personne ne l'a jamais fait. On découvre toujours des erreurs mineures. La plupart des gens qui font les malins sur le sujet n'ont pas idée du quart des problèmes qu'il peut y avoir. Avec le recul sur Java 4/5/6 Sun s'en tire très très très bien. Pour Java 7 il va falloir attendre un peu pour avoir du recul. Il y a au moins une erreur grave dans JAXP mais on va surement en trouver d'autres.
        
        Personne n'a envi de revalider les logiciels. Si t'as testé sur Java 5, t'impose Java 5 basta. Ça c'est le merveilleux monde de l'entreprise qui n'a rien de spécifique à Java. Ça t'évite de rencontrer les deux problèmes précédents.
        
        [^] # Re: Les vrais ajouts
        
        Posté par ckyl le 29 juillet 2011 à 16:19. Évalué à 3.
        
        Je pense que si Sun avait réellement cherché à garder une compatibilité parfaite, il n'aurait pas laissé la possibilité d'installer plusieurs JVM en parallèle sur Windows.
        
        Je pense que si tu as un avis pertinent sur le sujet tu peux me sortir une belle et longue liste de régressions ;)
      - [^] # Re: Les vrais ajouts
        
        Posté par devnewton 🍺 (site web personnel) le 29 juillet 2011 à 11:44. Évalué à 6.
        
        Le mieux serait surtout de virer ce putain d'equals et de surcharger =
        
        Une solution plus simple serait d'avoir deux opérateurs/méthodes distinctes:
        
        String a="toto",b="toto"; a.equals(b);//true, comparaison par valeur a.is(b);//false, comparaison d'instance null.equals(a);false null.is(a);false int x,y; x.equals(y);//ok x.is(y);//erreur, cette méthode n'existe pas
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
        
        [^] # Re: Les vrais ajouts
        
        Posté par barmic le 29 juillet 2011 à 22:23. Évalué à 2.
        
        String a="toto",b="toto"; a.equals(b);//true, comparaison par valeur a.is(b);//false, comparaison d'instance null.equals(a);false null.is(a);false int x,y; x.equals(y);//ok x.is(y);//erreur, cette méthode n'existe pas
        
        Tu veux au passage que null deviennent un objet ? Ca m'enchante pas vraiment (ou alors il faut que l'usage d'une méthode sur lui envoie dans les choux dans tout les cas).
        
        Pour les 3 dernières lignes, je ne comprends pas très bien. Tu veux de l'autoboxing, mais pas vraiment ou remplacer les types primitifs par des objets ?
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Les vrais ajouts
        
        Posté par devnewton 🍺 (site web personnel) le 30 juillet 2011 à 01:24. Évalué à 7.
        
        J'ai juste inventé une syntaxe pour illustrer une idée, mais sur le principe je ne vois pas pourquoi null ne serait pas un objet, ni pourquoi les types primitifs n'auraient pas de méthode...
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
        
        [^] # Re: Les vrais ajouts
        
        Posté par pasScott pasForstall le 30 juillet 2011 à 01:38. Évalué à 1.
        
        je ne vois pas pourquoi null ne serait pas un objet
        
        Ca se tient. Ou un objet spécial qui retourne toujours faux et ne fait rien.
        
        ni pourquoi les types primitifs n'auraient pas de méthode...
        
        Probablement parce que ça en ferait des objets et plus des types primitifs :)
        
        If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
        
        [^] # Re: Les vrais ajouts
        
        Posté par devnewton 🍺 (site web personnel) le 30 juillet 2011 à 11:26. Évalué à 2.
        
        Probablement parce que ça en ferait des objets et plus des types primitifs :)
        
        Pas forcément. Ca peut être juste une même écriture pour des opérations identiques.
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
        
        [^] # Re: Les vrais ajouts
        
        Posté par pasScott pasForstall le 30 juillet 2011 à 12:56. Évalué à -4.
        
        Ben c'est un peu la definition d'un objet...
        
        If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
        
        [^] # Re: Les vrais ajouts
        
        Posté par barmic le 30 juillet 2011 à 03:11. Évalué à -1.
        
        J'ai juste inventé une syntaxe pour illustrer une idée, mais sur le principe je ne vois pas pourquoi null ne serait pas un objet,
        
        Parce que c'est ce qui est le plus logique ?
        
        ni pourquoi les types primitifs n'auraient pas de méthode...
        
        Ils deviendrais des classes tout simplement (tu as déjà toutes les classes qui faut pour dans Java soit dis en passant).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Les vrais ajouts
        
        Posté par pasScott pasForstall le 30 juillet 2011 à 06:35. Évalué à 2.
        
        Parce que c'est ce qui est le plus logique ?
        
        Pas forcement :)
        En objective c, nil est parfaitement safe et tu peux appeler ce que tu veux dessus. Ca retournera juste 0, caste vers le type qui va bien (donc nil, NO, un struct aléatoire etc.)
        
        Bon, apres, on peut discuter qu'en obj c, en vrai, on appelle pas une méthode, mais on envoie un message a un pointeur, et que si le pointeur est nil, alors on envoie rien.
        Bon.
        C'est pas faux :)
        
        Au final, quand tu regardes bien, c'est des fonctions C dont l'objet parent est en fait le premier paramètres de la fonction.
        
        If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
        
        [^] # Re: Les vrais ajouts
        
        Posté par jean le 03 août 2011 à 12:27. Évalué à 1.
        
        En objective c, nil est parfaitement safe et tu peux appeler ce que tu veux dessus. Ca retournera juste 0, caste vers le type qui va bien (donc nil, NO, un struct aléatoire etc.)
        
        On ne doit pas avoir la même définition de safe.
        
        [^] # Re: Les vrais ajouts
        
        Posté par devnewton 🍺 (site web personnel) le 30 juillet 2011 à 11:28. Évalué à 5.
        
        Parce que c'est ce qui est le plus logique ?
        
        Quelle logique?
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
      - [^] # Re: Les vrais ajouts
        
        Posté par calvin2001 le 29 juillet 2011 à 14:33. Évalué à 2.
        
        La comparaison des String est effectivement casse-gueule en Java.
        
        L'opérateur = compare des types de base (int, double, ...).
        La méthode equals (présente dans la classe Object) sert à comparer des objets.
        
        En l’occurrence, String est un objet.
        
        Si tu utilise = pour comparer des String, tu compares leur référence, pas le contenu.
        Si tu utilise equals, tu compares bien le contenu.
        
        Alors parfois, le = fonctionne. Pourquoi ? L'explication est dans la doc) de String : un pool de String est maintenu par la classe. Quand tu en crée un nouveau est qu'il est dans le pool, alors c'est la même référence qui est utilisée. Sinon, c'est un autre objet.
        
        (voir StackOverflow pour plus de détail).
        
        Notamment : "a" == "a" peut retourner true ou false selon que "a" fait partie du pool ou pas
        new String("a") == new String("a") retourne toujours false (deux objets différents).
        
        A noter que dans des langages de scripts comme Groovy, l'opérateur == est surchagé pour toujours faire .equals. En groovy, donc : new String("a") == new String("a") retourne toujours true.
        
        [^] # Re: Les vrais ajouts
        
        Posté par CrEv (site web personnel) le 29 juillet 2011 à 14:44. Évalué à 4.
        
        On peut l'expliquer comme on veut, en terme d'usage c'est juste de la merde.
        J'aimerais bien voir du code où on a intérêt de tester les références de String.
        Ensuite j'aimerais bien qu'on m'explique qu'il est logique de prendre ce cas particulier comme base et de balancer un equals comme cas particulier (parce que bon l'égalité dans le cas général c'est quand même ==).
        
        D'ailleurs, je sais plus qu'elle est la ~~vrai~~ raison de la non inclusion de la surcharge d'opérateur. Je crois que c'est tellement con que je ne retiens pas.
        (tout comme celle pour les valeurs par défaut)
        
        [^] # Re: Les vrais ajouts
        
        Posté par calvin2001 le 29 juillet 2011 à 15:07. Évalué à 3.
        
        On peut l'expliquer comme on veut, en terme d'usage c'est juste de la merde.
        
        J'ai pas dit que c'était bien. De toute façon, en Java, quand on compare des Object avec ==, c'est que l'on sait ce que l'on fait. La base que l'on apprend, c'est de comparer les objets avec equals, et String ne fait pas exception à la règle.
        
        J'aimerais bien voir du code où on a intérêt de tester les références de String
        
        Utiliser == est bien plus rapide que d'utiliser equals. Il y a des outils/API qui manipulent beaucoup de String (XML, ...), et là ça devient intéressant de pouvoir rapidement savoir si 2 String ont la même valeur.
        
        parce que bon l'égalité dans le cas général c'est quand même ==
        
        == teste l'égalité des référence quand tu l'utilises sur des objets. Le cas général, c'est == pour les types de base, equals pour les objets.
        
        D'ailleurs, je sais plus qu'elle est la vrai raison de la non inclusion de la surcharge d'opérateur. Je crois que c'est tellement con que je ne retiens pas.
        
        Je ne la connais pas, mais comme toi, je regrette aussi qu'on ne puisse pas le faire.
        
        [^] # Re: Les vrais ajouts
        
        Posté par CrEv (site web personnel) le 29 juillet 2011 à 15:30. Évalué à 2.
        
        Utiliser == est bien plus rapide que d'utiliser equals.
        
        C'est surtout qu'en réalité c'est pas du tout la même chose.
        
        ça devient intéressant de pouvoir rapidement savoir si 2 String ont la même valeur.
        
        Mais justement, == ne fonctionne pas dans ce cas
        
        Le cas général, c'est == pour les types de base, equals pour les objets
        
        Le cas général c'est, lorsqu'on compare des String, de comparer leur valeur. Comparer la référence d'une String j'aimerais bien le voir dans un cadre classique...
        
        [^] # Re: Les vrais ajouts
        
        Posté par calvin2001 le 29 juillet 2011 à 15:42. Évalué à 2.
        
        C'est surtout qu'en réalité c'est pas du tout la même chose.
        
        Oui, donc par défaut, c'est equals pour les objet. Ceux qui utilisent == pour les objets le font pour de bonnes raisons.
        
        Mais justement, == ne fonctionne pas dans ce cas
        
        Ben si : si == te répond true, tu es sûr que les 2 chaînes sont égales (la chaîne est dans le pool). S'il te répond false, alors il faut vérifier avec equals.
        
        == pourra te donner des faux positifs, mais s'il te dit true, alors tu es sûr du résultat, et ton programme gagne du temps.
        
        Le cas général c'est, lorsqu'on compare des String, de comparer leur valeur. Comparer la référence d'une String j'aimerais bien le voir dans un cadre classique...
        
        Comme je l'ai déjà dit, comparer la référence d'une String est fait par les librairies de parsing XML pour gagner du temps. Mais en général, je suis d'accord, on n'en a pas besoin dans les programmes que l'on peut écrire.
        
        En Java, le cas général, c'est == pour les types de base, et equals pour les objets (tous les objets, y compris les String). Si tu suis cette règle, pas de problème, tu compares bien les String par leur valeur dans tous les cas.
        
        [^] # Re: Les vrais ajouts
        
        Posté par calvin2001 le 29 juillet 2011 à 15:44. Évalué à 1.
        
        == pourra te donner des faux positifs, mais s'il te dit true, alors tu es sûr du résultat, et ton programme gagne du temps.
        
        Pardon, faux-négatifs, bien sûr
        
        [^] # Re: Les vrais ajouts
        
        Posté par CrEv (site web personnel) le 29 juillet 2011 à 15:48. Évalué à 2.
        
        OK, donc au final je pense qu'on est d'accord.
        Le cas général (non pas en java mais pour un programmeur) c'est de tester l'égalité de deux chaînes de caractères (en java c'est malheureusement equals). Et donc le cas général est chiant à utiliser en Java.
        Maintenant, ce que tu rajoutes, c'est que == est bien pour des optimisations. Mais les optimisations c'est justement pas le cas général.
        (par contre, merci, j'avais pas pensé à utiliser les deux conjointement, dans ce sens)
        
        [^] # Re: Les vrais ajouts
        
        Posté par calvin2001 le 29 juillet 2011 à 15:54. Évalué à 1.
        
        Et donc le cas général est chiant à utiliser en Java.
        
        On est bien d'accord :) C'est pour ça aussi que j'aime Groovy : le == sur les String fait bien la comparaison des valeurs comme on s'y attend, et pas des références.
        
        (par contre, merci, j'avais pas pensé à utiliser les deux conjointement, dans ce sens)
        
        Avec plaisir
        
        [^] # Re: Les vrais ajouts
        
        Posté par barmic le 29 juillet 2011 à 22:56. Évalué à 2.
        
        (par contre, merci, j'avais pas pensé à utiliser les deux conjointement, dans ce sens)
        
        Tu n'a jamais vu de fonctions equals() ainsi ?
        
        public boolean equals(Object o) { if(o == this) { return true; } if(o instanceof MaClasse) { MaClasse mc = (MaClasse) o; return Objects.equals(this.getX(), mc.getX()); // J'utilise Objects (Java 7) par comodité pour gérer les valeurs null } }
        
        Tu économise beaucoup en évitant la réflexion et tout les tests plus ou moins lourd.
        C'est du code appelé dans les collections.
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Les vrais ajouts
        
        Posté par barmic le 29 juillet 2011 à 22:46. Évalué à 1.
        
        Le cas général c'est, lorsqu'on compare des String, de comparer leur valeur. Comparer la référence d'une String j'aimerais bien le voir dans un cadre classique...
        
        Tu voudrais que String ne soit pas une classe mais un type primitif ?
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Les vrais ajouts
        
        Posté par barmic le 29 juillet 2011 à 22:36. Évalué à 2.
        
        J'aimerais bien voir du code où on a intérêt de tester les références de String.
        
        Ça peut être pratique quand tu a des objets avec chacun qui pointe sur l'autre. Tu veut avoir une fonction addX() sur chacun qui fait un truc du genre :
        
        void addX(X x) { if(this.x != x) { this.x.removeY(this); this.x = x; this.x.addY(this); } }
        
        et de même pour le addY() de X. Je pense que garder cette fonctionnalité autrement est peut être plus lourd. C'est quelques chose qui peut être utils dans des Collections particulière.
        
        Pour la surcharge d'opérateurs, même si j'aime beaucoup cette possibilité en C++, il n'y a que très peu de cas (quelques types comme les matrices, quaternions, etc; l'opérateur == à la rigueur et l'opérateur / pour les chemins de fichiers comme en boost) où c'est une bonne idée.
        
        Mais franchement, c'est ridicule d'attaquer le langage sur un point aussi insignifiant que le ==. Il y a bien d'autres angles bien plus intéressants (et plus problématique).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Les vrais ajouts
        
        Posté par pasScott pasForstall le 30 juillet 2011 à 01:01. Évalué à 0.
        
        C'est pas la premiere fois qu'il s'en plaint.
        De ce que je comprends entre les lignes, son problème c'est surtout qu'il est trop fainéant pour taper .equals et veut juste taper == a la place de .equals.
        A chaque fois on a droit au cas d'école irréaliste que personne n'a jamais vu dans la vraie vie et qui ne ressort que dans les trolls foireux sur java.
        'fin si ça pose réellement un problème, va falloir revoir ses concepts d'objets et tout le tralala, y'a un problème fondamental a l'écriture du code qui est pas du au langage la...
        
        Tu peux tourner le problème comme tu veux, les deux sont nécessaires.
        Apres, quand tu regardes les choses de plus près, il se trouve que String est immuable de toute façons. Par design, c'est un object jetable, et tester les pointeurs n'a pas franchement de sens sur des objets immuable, tout ce qui est intéressant c'est l'égalité de valeur (ben ouais, c'est pas comme si tu pouvais le modifier, alors qu'est ce qu'on en a branler du pointeur?).
        Et c'est marrant, c'est exactement la meme chose avec Integer et ses potes, et c'est son autre exemple qu'il ressort a chaque fois (quoique la l'autoboxing peut jouer des tours).
        
        Bref, ce que j'en conclu de tout ça, c'est surtout une mauvaise maitrise de concept objet et d'architecture logicielle.
        Ou une sacrée faineantise.
        Ou alors, mais j'en doute, un besoin compulsif de troller pour le plaisir :)
        
        If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
      - [^] # Re: Les vrais ajouts
        
        Posté par pasScott pasForstall le 29 juillet 2011 à 21:45. Évalué à 1.
        
        Quelle est la logique dans le code suivant:
        MyObject foo = new MyObject(param); MyObject bar = new MyObject(param2); OtherObject toto = new OtherObject(param1); foo == bar; // vrai. ou faux. Ca dépend. toto == bar; // vrai. ou faux. ça dépend. Ou pas. Faut voir au runtime en fait.
        
        Note: == peut avoir été surcharge.
        Ou pas.
        Et last but not least, que fait le code suivant:
        private void bla(T foo) { for(T object in this.list) { if(object == foo){ // vrai. ou faux. mais peut être pas. Parcourt potentiellement un graphe monstrueux et tire 500 objets d'une base de données par lazy loading. En fait on sait pas. D'ailleurs on sait pas si le mec qui a écrit chercher le meme pointeur ou un objet équivalent. // wouhou! } } }
        
        Note: == peut avoir été surcharge.
        Ou pas.
        Certes ton example est étonnant au premier abord, mais, il est parfaitement spécifie et tout le monde sait exactement pourquoi il fonctionne comme il fonctionne.
        Tu lit le code tu sais exactement ce que ça va donner. Et tu sais aussi comment l'écrire pour que ça donne exactement ce que tu veux.
        Cela dit, l'exemple reste parfaitement logique, l'utilisation avec new donne exactement le résultat escompte. Quand tu by-pass new, t'as des résultats bizarre, mais hé, t'as pas instantie ces objects toi meme, hein? Alors? De quoi tu te plains?
        
        Le gros problème de la method bla écrite plus haut, est que personne ne peut dire ce que cette méthode va faire, et pire encore, c'est fondamentalement impossible de dire ce que cette méthode est censée faire. L'intention n'est pas exprimable dans le langage, parce qu'un meme symbole a 2 sémantique complètement opposée.
        Ca dépend du contexte et des objets qui sont passes en entrée, et ça c'est fondamentalement mauvais.
        
        Ca a pas l'air de te plaire, mais il ya une enorme difference entre == et equals.
        Utiliser le meme symbole selon le contexte pour l'un ou l'autre est une GROSSE erreur de design.
        Sans compter qu'un jour, tu vas vouloir a la fois utiliser l'égalité de pointeur et l'égalité de valeur, et t'auras l'air bien malin avec ton == surcharge.
        
        Partant de la, il faut bien les différencier.
        
        Au passage, bon courage pour implementer ta surcharge de == avec des proxy. Et c'est pas comme si les proxy était un concept étrange en java.
        
        Quand tu regardes les choses:
        - Le premier est une simple égalité de pointeur. Pas de code qui tourne, on compare juste deux entiers. == est parfaitement adapte, concision et ça correspond bien au model mental.
        - Le deuxième implique une logique métier, potentiellement très couteuse (tu peux avoir a parcourir une partie de ton graphe d'objet pour déterminer l'égalité). Logique métier implique une méthode. Un symbole == n'est pas adapte car il n'est pas associe a cette notion d'exécution de code.
        
        Le choix est parfaitement logique et adapte dans le cas général. Maintenant, il se trouve que les chaines constantes subissent qq optimisations, est ce que ça veut dire qu'il faut laisser tomber un design qui marche tres bien pour le reste des classes?
        Va falloir argumenter sérieusement parce que beaucoup ont besoin de faire la différence entre égalité de pointeur et égalité de valeur, surcharge == ne va que t'apporter des problemes impossible a résoudre, par design.
        
        Java a au moins le mérite d'intégrer ce concept dans le langage, amuse toi a écrire du code un tant soit peut générique (genre sélection automatique dans une dropdown) en ActionScript, t'es oblige de te baser sur des conventions parce que le langage n'est pas assez riche.
        
        If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
        
        [^] # Re: Les vrais ajouts
        
        Posté par 2PetitsVerres le 30 juillet 2011 à 14:12. Évalué à 3.
        
        Et si dans ton exemple on remplace '==' par '.equals()' on peut aussi dire
        
        Le gros problème de la method bla écrite plus haut, est que personne ne peut dire ce que cette méthode va faire, et pire encore, c'est fondamentalement impossible de dire ce que cette méthode est censée faire.
        
        Je ne vois pas où est la différence.
        
        Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
        
        [^] # Re: Les vrais ajouts
        
        Posté par barmic le 30 juillet 2011 à 14:17. Évalué à 3.
        
        Tu fais un appel explicite à une méthode. Tu sais du premier coup que ce n'est pas un mécanisme interne du langage mais bien un envoie de message sur un objet.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Les vrais ajouts
        
        Posté par 2PetitsVerres le 30 juillet 2011 à 14:30. Évalué à 3.
        
        Ah ouais, un peu comme si dans la doc il était marqué "'==' n'est pas un mécanisme interne du langage mais bien un envoi de message sur un objet"
        
        Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
        
        [^] # Re: Les vrais ajouts
        
        Posté par barmic le 30 juillet 2011 à 14:38. Évalué à -2.
        
        Avec des « si », tu peut faire pleins de choses.
        
        Reste qu'à la lecture, d'un code qu'il soit Java, C++, python, perl ou autre tu sais que x.foo(y) est un envoie de message alors que x == y est spécifique à chaque langage.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Les vrais ajouts
        
        Posté par Antoine le 30 juillet 2011 à 15:43. Évalué à 6.
        
        tu sais que x.foo(y) est un envoie de message alors que x == y est spécifique à chaque langage.
        
        Sauf que cet "envoi de message" n'a justement rien à voir d'un langage à l'autre. Il faut arrêter de penser qu'il y a un "modèle objet" commun à tous ces langages.
        
        (en C++, par exemple, les méthodes sont non-virtuelles par défaut; en Python, une méthode peut être définie sur l'instance et masquer celle définie sur la classe; etc.)
        
        [^] # Re: Les vrais ajouts
        
        Posté par barmic le 30 juillet 2011 à 16:52. Évalué à -1.
        
        Un langage est considéré comme objet s'il permet de manipuler des objets. Ceux-ci étant des variables contenant un ensemble de variables et un ensemble de méthodes que l'on peut appliquer à cet objet.
        
        Tu nous parle de détail d'implémentation. Il y a dans tout les langages objets des envoies de messages et tout les langages qui utilisent une notation "pointée" s'en servent pour l'envoie de message (alors qu'il n'y en a qu'un sous ensemble qui permettent de manipuler les opérateurs).
        
        Il est nettement plus logique de considérer que == fait parti du langage et s'applique à des concepts plus bas niveau que .equals() dont le mécanisme est aussi simple que logique.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Les vrais ajouts
        
        Posté par Antoine le 30 juillet 2011 à 17:45. Évalué à 2.
        
        Tu nous parle de détail d'implémentation
        
        Faux. Ce sont des aspects de la sémantique de ces langages qui sont officiels, documentés, testés et maintenus, et les développeurs compétents les ont à l'esprit quand ils écrivent du code. Exactement comme la façon dont sont invoqués les opérateurs comme ==.
        
        J'ai franchement l'impression que tu connais peu ce dont tu parles, et la discussion devient assez ennuyeuse et stérile.
        
        [^] # Re: Les vrais ajouts
        
        Posté par barmic le 30 juillet 2011 à 19:47. Évalué à 2.
        
        Tu connais un langage objet qui n'a pas d'appel de méthode sur un objet parce que dans le commentaire précédent tu affirmais que tout les langages objets ne l'ont pas.
        
        Après oui savoir comment sa fonctionne est important je n'ai pas dis le contraire. Comprendre ce qu'est le polymorphisme et savoir ce qu'est une fonction virtuelle est important et différencie ces langages. La dynamicité et la réflexion aussi. Enfin le modèle d'exécution est très important dès que tu veut faire des choses complexes (gérer des sections critiques en Java est très fortement impacté par le fait que chaque objet possède son propre mutex).
        
        J'ai franchement l'impression que tu connais peu ce dont tu parles, et la discussion devient assez ennuyeuse et stérile.
        
        Pour moi c'est quand on commence à s'attaquer aux individus plutôt qu'à tenter de présenter des arguments que le débats deviens ennuyeux.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Les vrais ajouts
        
        Posté par Antoine le 30 juillet 2011 à 21:39. Évalué à 2.
        
        Tu connais un langage objet qui n'a pas d'appel de méthode sur un objet parce que dans le commentaire précédent tu affirmais que tout les langages objets ne l'ont pas.
        
        Non, relis. Je veux bien croire que mes messages sont concis, mais je n'ai pas dit cela.
        
        Après oui savoir comment sa fonctionne est important je n'ai pas dis le contraire.
        
        Tu as dit "tu nous parle de détail d'implémentation", ce qui est faux. Maintenant je n'ai pas envie de refaire le débat, donc si tu n'as rien à ajouter, restons-en là.
        
        [^] # Re: Les vrais ajouts
        
        Posté par jean le 03 août 2011 à 12:39. Évalué à 2.
        
        Un langage est considéré comme objet s'il permet de manipuler des objets. Ceux-ci étant des variables contenant un ensemble de variables et un ensemble de méthodes que l'on peut appliquer à cet objet.
        
        Ta définition est beaucoup trop large et fait de Perl un langage à objets, ce qu'il est autant que le langage machine. On peut utiliser une méthodologie objet avec presque tous les langages de programmation, mais un langage à objet doit intègrer dans son expressivité des traits objets comme l'héritage ou les classes virtuelles.
        
        [^] # Re: Les vrais ajouts
        
        Posté par pasScott pasForstall le 30 juillet 2011 à 22:12. Évalué à -2.
        
        La difference, c'est que l'un fait une egalite de pointeur, l'autre de valeur.
        les deux sont definis, soit dans le langage soit sur Object et tu sais ce qu'ils sont cense faire.
        
        Si t'utilise la surcharge d'operateur pour faire l'un a la place de l'autre, == ne veut plus rien dire.
        Quand tu lit == tu sais pas si le mec pensait egalite de pointeur ou de valeur.
        Tu ne peux pas connaitre l'intention du developeur.
        
        Et quand t'ecris du code un tant soit peu generique, t'es meme certain que ca va pas marcher pour tous les objets dont == a ete surcharge.
        
        If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
        
        [^] # Re: Les vrais ajouts
        
        Posté par 2PetitsVerres le 30 juillet 2011 à 22:40. Évalué à 3.
        
        Je sais tout ce que tu dis là. Mais je ne vois toujours pas en quoi ce serait mal de pouvoir utiliser '==' comme égalité de valeur (bien entendu si ça avait été pensé comme ça depuis le début) car :
        
        il est beaucoup plus courant de s'intéresser à l'égalité de valeur
        
        dans la plupart des cas également, on s'attend à avoir une relation d'égalité symétrique. Or a.equals(b) est une écriture asymétrique (mais dans le cas d'une surcharge de l'opérateur == on n'est pas sûr de cette symétrie, qui est effectivement dépendante de l'implémentation)
        
        Bien entendu ça n'aurait marché que si ça avait été pensé comme ça depuis le début, avec une autre façon de pouvoir tester l'égalité de pointeur dans les cas (moins nombreux à mon avis) où c'est cette information que l'on veut (genre a'address = b'address)
        
        Et quand t'ecris du code un tant soit peu generique, t'es meme certain que ca va pas marcher pour tous les objets dont == a ete surcharge.
        
        Moi qui croyait que dans 110% des cas le programmeur Java n'avait pas à se poser des questions sur les pointeurs…
        Plus sérieusement, dans une application écrite en java, quels sont les applications pratiques de l'égalité de pointeur ? La gestion d'un pool d'objet ? Généralement la partie «métier» va jouer sur les valeurs, et tout ce qui est plus bas niveau pourrait jouer sur des pointeurs, non ? Et je pense que ce sont les gens qui s'occupent du niveau plus bas qui doivent le mieux connaître leur langage, et donc connaître la syntaxe particulière de la comparaison de pointeur, et qu'on devrait laisser aux autres la syntaxe plus jolie du '==' pour la comparaison de valeur (qui en plus aurait l'avantage d'être cohérent avec l'égalité de valeur des types de base…)
        
        Enfin, bon, je m'en fous un peu, je trouverais juste ça plus élégant. Mais je ne fais pas de java dans la vie de tous les jours, et pas d'allocations dynamiques, donc j'ai assez peu de problèmes de pointeurs.
        
        Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
        
        [^] # Re: Les vrais ajouts
        
        Posté par pasScott pasForstall le 30 juillet 2011 à 23:57. Évalué à -4.
        
        Juste pour être sur qu'on est sur la meme page, ce que tu propose, c'est d'avoir == pour l'égalité de valeur tout le temps, et equals pour celle de pointeur?
        Ou juste surcharger == pour faire de l'égalité de valeur ponctuellement, avec un plan b pour l'égalité de pointeurs?
        
        Le problème fondamental avec la surcharge de == (ou meme l'échange de == et de equals), c'est que ça transforme une opération très simple de comparaison d'entiers en appel de methode sur des objets, avec tous les problèmes que ça amène. Et en plus, c'est impossible de savoir simplement en lisant le code si ça va aller a une méthode ou pas.
        
        En gros:
        1) c'est plus nulle safe et ça pete la symetrie de ==.
        Object a = null;
        Object b = new Object()
        a == b; // NPE
        b == a; // false.
        
        2) Ca rend le code beaucoup plus difficile a relire, vu qu'il est désormais impossible de savoir ce que == est censé faire. Ca c'est un énorme problème a mes yeux. Du code, ça doit se lire comme un livre. Si lire du code se lit dans un langage naturel, très expressif (modulo les quelques trucs technique, évidemment), la maintenabilite a fait un énorme bond en avant. N'importe qui peut lire le code, se rendre compte d'un problème. Ou s'occuper d'un bug et comprendre 'achement plus vite ce qu'il se passe.
        Et c'est encore plus important en java qui est majoritairement utilise dans un contexte entreprise, ce qui veut dire appli critiques maintenues pendant des années, voire des dizaines d'années, et très souvent ecrites/maintenues par une bande de bras casses. La simplicité et la clarté sont vitales dans ce contexte. Non pas qu'ils soient pas importants dans d'autre contexte, mais en java c'est vraiment important.
        
        3) Potentiellement, tes objets vont lazy loader dans une base de données sur equals. Ton code qui parait tout innocent va maintenant aller tirer un gros paquet de données de façon pas visible du tout.
        
        4) il est maintenant interdit d'utiliser == dans un bout de code un tant soit peu générique, vu que tu peux pas savoir ce que ça va faire.
        
        5) Conceptuellement, si tu veux appeler une méthode sur un objet, ben appelle une méthode dessus :) Plutot que de mapper un opérateur a une méthode implicitement.
        
        Bon, ça c'est pour les problèmes que ça ammene.
        
        Niveau avantage, on gagne quoi au juste? J'ai du mal a comprendre en fait.
        Ce qui dérange c'est de taper .equals a la place de == ?
        Ben ouais, mais bon. Vous etes vraiment si fainéant que ça? C'est quoi la prochaine étape, remplacer new par n parce que c'est trop long a taper?
        
        D'une part, c'est pas la fin du monde, c'est pas comme si .equals était dur a taper. Et c'est pas comme si on avait des environnements de dev qui s'occupe de taper la moitié du code a la place du dev.
        Donc, on perd énormément en clarté, tout ça pour économiser quelques caractères a droite a gauche?
        
        Plus sérieusement, dans une application écrite en java, quels sont les applications pratiques de l'égalité de pointeur ?
        
        Savoir si les instances sont les memes.
        Ca a son utilité, tu peux vouloir vérifier que deux objets pointent au meme endroit, sans se soucier de savoir s'ils ont la meme valeur ou pas.
        
        Généralement la partie «métier» va jouer sur les valeurs, et tout ce qui est plus bas niveau pourrait jouer sur des pointeurs, non ?
        
        Ou pas, tu peux pas tirer de generalites sur un truc aussi large qu'un langage. Et si ton domaine c'est le bas niveau, ta logique métier va jouer sur les valeurs ET les pointeurs.
        
        qui en plus aurait l'avantage d'être cohérent avec l'égalité de valeur des types de base…
        
        Comment ça? == est cohérent, il compare le contenu des variables.
        Il ne s'occupe pas du sens que tu donnes a ces variables.
        
        Java a clairement des problèmes, mais pas a ce niveau.
        Parlez moi de leur implémentation foireuse des generics, de l'absence de closure (encore que ça m'a jamais vraiment manque ça), de l'API Date qui est une énorme blague, de l'absence de properties, de l'absence de collections immuables, de l'absence de string/nombre mutables, de leur fast iterator des bois qui te pete des NPE sur une collection nulle et des autres trucs que j'oublie.
        
        Et comme dit ailleurs, faut pas oublier que le langage a maintenant 20 ans. Un des objectifs c'était "du code écrit aujourd'hui tournera encore dans 20 ans", cet objectif est clairement atteint.
        Dans un domaine aussi dynamique que le développement soft, je trouve que sun s'en est plutôt bien sorti dans l'ensemble.
        
        If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
    - [^] # Re: Les vrais ajouts
      
      Posté par un_brice (site web personnel) le 29 juillet 2011 à 11:52. Évalué à 3.
      
      Même en dehors de l'autoboxing, le switch peut est (si c'est bien fait) implémenté par quelque chose de bien plus efficace qu'une succession de tests, c'est sans doute l'une des raisons pour lesquelles il a un mot clef dédié. Autant dans le cas des entiers c'pas bien grave, autant pour des chaînes de caractères ça peut être critique (O(ln(nombre de possibilités)) au lieu de O(nombre de possibilités*taille de la chaîne)).
      
      Si on utilise un truc à base d'equals ça marche pas, et ça fait des appels de méthode « magiques » qui ne sont pas écrits dans le code source mais dans le langage (bon, OK, le nouveau système de try-with fout ça en l'air mais c'est quand même plus explicite de mon point de vue)
      - [^] # Re: Les vrais ajouts
        
        Posté par claudex le 29 juillet 2011 à 12:14. Évalué à 1.
        
        Utiliser les méthodes equals n'empêche pas d'avoir des cas particuliers pour certains objets fort utilisé comme les Strings.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Les vrais ajouts
        
        Posté par barmic le 29 juillet 2011 à 22:57. Évalué à 4.
        
        Et le KISS on en fait quoi ? :)
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Les vrais ajouts
        
        Posté par 2PetitsVerres le 30 juillet 2011 à 14:13. Évalué à 5.
        
        Merde j'ai dû rater un truc. On ne parle plus de Java ?
        
        Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
    - [^] # Re: Les vrais ajouts
      
      Posté par hsyl20 (site web personnel) le 29 juillet 2011 à 14:41. Évalué à 2.
      
      Le mieux c'est de pouvoir faire du pattern-matching. De pouvoir définir des "extractors" pour n'importe quel objet, etc.
  - [^] # Re: Les vrais ajouts
    
    Posté par barmic le 29 juillet 2011 à 22:16. Évalué à 2.
    
    C'est peut-être pas fondamental mais démontre juste le retard qui existe chez Java (ok, plus sur ce point) et surtout le côté bas niveau du langage.
    Et le switch c'est plus que pratique et beaucoup plus propre si tu as plus que 3 strings. Ne pas le gérer c'est assez difficilement justifiable.
    
    Il y a des langages à qui on ne le reproche pas et qui pourtant ne gèrent pas du tout de switch (comme python). Le C et le C++ ne le gère pas pour les structs/objets.
    
    Nous sommes d'accord perl (avec given/when) et les langages fonctionnels explosent tout les autres langages avec, mais faut bien comprendre que tout les langages ne peuvent pas être au même niveau ;)
    
    Pour le reste, ce que j'adore c'est que je connais des dev java qui disent que diamond n'est pas une bonne idée.
    
    Les cas où ce n'est pas une bonne idée sont tordus, théoriques et la faute viens de code pourris.
    
    Idem pour le resources.
    
    Là je vois pas.
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    - [^] # Re: Les vrais ajouts
      
      Posté par Antoine le 30 juillet 2011 à 01:49. Évalué à 2.
      
      Il y a des langages à qui on ne le reproche pas et qui pourtant ne gèrent pas du tout de switch (comme python).
      
      En même temps, si tu veux un équivalent de switch sur une chaîne de caractères, il est assez trivial de faire de l'appel de méthode paramétrique en Python. Ou si tu veux utiliser des fermetures, avec un dictionnaire.
      - [^] # Re: Les vrais ajouts
        
        Posté par barmic le 30 juillet 2011 à 03:26. Évalué à -1.
        
        il est assez trivial de faire de l'appel de méthode paramétrique en Python.
        
        Qu'est ce donc ?
        
        Ou si tu veux utiliser des fermetures, avec un dictionnaire.
        
        J'ai vu deux solutions :
        {'option1': function1, 'option2': function2, 'option3': function3, 'option4': function4}[value]()
        
        Il faut déclarer les fonctions avant et garder la cohérence entre le nom des fonctions et leur appel (aucun IDE ne t'aideras et je doute qu'un interpréteur sache valider l'instruction avant son éxecution).
        Seconde solution
        result = { 'a': lambda x: x * 5, 'b': lambda x: x + 7, 'c': lambda x: x - 2 }[value](x)
        
        C'est bien quand ce que tu as comme code est compact, si non c'est illisible (puis les lambdas pose des limitations (Stupid lambda tricks)).
        Je parle pas du détournement que c'est d'un dictionnaire, de la gestion des defaults (il faut utiliser la méthode get()...), de la lecture à l'envers (la variable testée est à la fin de l'instruction sur la dernière ligne),...
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Les vrais ajouts
        
        Posté par Antoine le 30 juillet 2011 à 09:01. Évalué à 4.
        
        il est assez trivial de faire de l'appel de méthode paramétrique en Python.
        
        Qu'est ce donc ?
        
        Un exemple fictif facilement compréhensible :
        
        class HTTPServerConnection: def handle_request(self, request): meth_name = "handle_" + request.method.upper() meth = getattr(self, meth_name, self.handle_other) return meth(request) def handle_GET(self, request): # etc. def handle_POST(self, request): # etc. def handle_other(self, request): # on arrive ici si la méthode HTTP n'est pas # reconnue
        
        Il faut déclarer les fonctions avant et garder la cohérence entre le nom des fonctions et leur appel
        
        L'idée avec ce genre d'idiome c'est que tes fonctions sont le plus souvent privées (histoire de découpler l'API de tes détails d'implémentation), donc il n'y a pas de raison de changer le nommage.
        
        [^] # Re: Les vrais ajouts
        
        Posté par Vador Dark (site web personnel) le 04 août 2011 à 00:25. Évalué à 1.
        
        Pour les performances et la sécurité, c'est quand même à éviter ce genre de choses.
        
        [^] # Re: Les vrais ajouts
        
        Posté par 2PetitsVerres le 30 juillet 2011 à 14:17. Évalué à 3.
        
        C'est bien quand ce que tu as comme code est compact, si non c'est illisible
        
        Je pense que c'est pareil dans un peu tous les langages, dans un switch (ou équivalent), si tu mets 20 lignes de code dans chaque case, ça va être dur à suivre.
        
        Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
        
        [^] # Re: Les vrais ajouts
        
        Posté par barmic le 30 juillet 2011 à 14:51. Évalué à 1.
        
        Entre 20 lignes et une expression (attention pas une instruction), il y a tout de même une grande différence tu ne crois pas ?
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: Les vrais ajouts
  
  Posté par reno le 29 juillet 2011 à 10:03. Évalué à 3.
  
  Merci pour le lien, la partie que je trouve amusante c'est qu'il me semble que c'est la troisième version pour les IO.
  Java c'est un escargot: ça bouge, mais alors l'évolution est d'une lenteur..
  La page que tu donnes à un sous lien (en Anglais) sur ce sujet, c'est hilarant ou triste selon l'humeur:
  http://today.java.net/pub/a/today/2008/07/03/jsr-203-new-file-apis.html
  
  Peut-être que Java finira par intégrer les évolutions de Scala/Kotlin, mais je pense qu'à ce rythme ce ne sera pas pour ce millénaire..
  - [^] # Re: Les vrais ajouts
    
    Posté par Antoine le 29 juillet 2011 à 15:28. Évalué à 3.
```
OutputStream out = p.newOutputStream(EnumSet<OpenOption>.of(StandardOpenOption.CREATE_NEW));
```
    Toute la beauté de Java condensée (?) en quelques caractères.
    - [^] # Re: Les vrais ajouts
      
      Posté par ckyl le 29 juillet 2011 à 15:56. Évalué à 2.
      Ou alors si utilises la vraie API et pas celle supposée dans un article de 2008:
      
      Path p = Paths.get("/tmp", "file.txt"); OutputStream os = Files.newOutputStream(p, StandardOpenOption.CREATE_NEW, StandardOpenOption.SPARSE);
      
      La laideur de Java n'a d'égal que l'ignorance crasse de la plupart de ses détracteurs :p
      - [^] # Re: Les vrais ajouts
        
        Posté par Antoine le 29 juillet 2011 à 16:10. Évalué à 10.
        
        C'est vrai que c'est beaucoup plus beau, au temps pour moi.
        
        [^] # Re: Les vrais ajouts
        
        Posté par ckyl le 29 juillet 2011 à 16:41. Évalué à 2.
        
        Histoire d'être constructif tu reproches quoi ?
        
        [^] # Re: Les vrais ajouts
        
        Posté par Alex le 29 juillet 2011 à 21:16. Évalué à 4.
        
        L'utilisation de 4 classes, ou la verbosité bien lourde
        
        [^] # Re: Les vrais ajouts
        
        Posté par barmic le 29 juillet 2011 à 23:45. Évalué à 2.
        
        J'en vois que 3 (un énumérateur c'est particulier). Il n'y a rien de globale et tout et vérifié à la compilation contrairement à d'autres langages (pour faire la même chose je parle).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Les vrais ajouts
        
        Posté par Alex le 30 juillet 2011 à 01:09. Évalué à 2.
        
        Bon même si yen a 3
        Sur les 2 exemples donnés, je trouve les 2 lourds, le premier à cause de cet affreux generic, le second pour sa verbosité.
        
        Néanmoins, critiquer un langage sur des exemples aussi simplistes est un peu limite
        Des exemples pareils, je pense qu'on en trouve partout
        
        [^] # Re: Les vrais ajouts
        
        Posté par Antoine le 30 juillet 2011 à 01:52. Évalué à 1.
        
        La verbosité par rapport à un truc du genre:
        
        f = open("/tmp/file.txt", "rb")
        
        (le StandardOpenOption.BIDULE étant particulièrement lourd, tout de même)
        
        [^] # Re: Les vrais ajouts
        
        Posté par Alex le 30 juillet 2011 à 02:12. Évalué à 5.
        
        L'exemple n'est pas très bon tout de même, l'utilisation d'une chaine pour les flags, c'est un truc qui ne se vérifie pas à la compile, donc un risque de bug que l'on ne découvrirait qu'au runtime.
        Autant prendre la version c++
        
        ofstream file; file.open("file.txt", ios::in );
        
        [^] # Re: Les vrais ajouts
        
        Posté par Antoine le 30 juillet 2011 à 03:03. Évalué à 1.
        
        Il y a plein de bugs qu'on ne peut découvrir qu'au runtime. Penser qu'on gagne quelque chose à rendre beaucoup plus complexe une chaîne de flags triviale telle que "rb" me semble totalement idiot. Surtout que c'est un truc qui apparaîtra dès que tu écris un test unitaire.
        
        [^] # Re: Les vrais ajouts
        
        Posté par barmic le 30 juillet 2011 à 03:33. Évalué à 3.
        
        C'est pas parce qu'il y a pleins de bugs qu'on ne détecte qu'à l'exécution qu'il est mauvais d'en découvrir avant. En plus la gestion par chaîne oblige à parser cette chaîne derrière là où en C++, on a de simples tests binaires.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Les vrais ajouts
        
        Posté par Antoine le 30 juillet 2011 à 09:24. Évalué à 1.
        
        C'est pas parce qu'il y a pleins de bugs qu'on ne détecte qu'à l'exécution qu'il est mauvais d'en découvrir avant
        
        C'est un compromis. Ce bug se manifeste de façon immédiate, évidente et déterministe (*). Il est contre-productif d'alourdir les écritures sous prétexte de le détecter à la compilation.
        
        (*)
        >>> f = open("LICENSE", "r") >>> f.write("bar") Traceback (most recent call last): File "<stdin>", line 1, in <module> IOError: File not open for writing
        
        En plus la gestion par chaîne oblige à parser cette chaîne derrière là où en C++, on a de simples tests binaires.
        
        On va gagner une fraction de microseconde à chaque ouverture de fichier, chouette.
        
        [^] # Re: Les vrais ajouts
        
        Posté par barmic le 30 juillet 2011 à 11:42. Évalué à 4.
        
        C'est un compromis. Ce bug se manifeste de façon immédiate, évidente et déterministe (*). Il est contre-productif d'alourdir les écritures sous prétexte de le détecter à la compilation.
        
        C'est faux, si tu n'ouvre ton fichier que dans des cas précis, il va falloir que tu entre dans ce cas précis pour arriver à le détecter.
        
        Chercher à être compacte à l'extrême n'a pas de sens. Le mode U ou u n'a rien d'intuitif. Chercher à gagner 5 à 10 caractères en perdant en lisibilité, en performance et en fiabilité, ça n'a pas de sens.
        
        Pour moi une constante ça doit être encapsulé dans une variable. Ca aide l'utilisateur de la fonction et ça permet de découpler l'implémentation de l'utilisation.
        
        En plus la gestion par chaîne oblige à parser cette chaîne derrière là où en C++, on a de simples tests binaires.
        
        On va gagner une fraction de microseconde à chaque ouverture de fichier, chouette.
        
        C'est là où l'on voit la différence entre des langages comme le C++ et le python. En python ils se foutent des performances et tentent de gérer le cas quand ils se retrouvent au pied du mur, en C++ la performance est prise en compte bien plus tôt (surtout quand c'est bénéfique pour pleins d'autres choses).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Les vrais ajouts
        
        Posté par BB le 30 juillet 2011 à 14:03. Évalué à 2.
        
        Pour ce que ça vaut :
        
        The argument mode points to a string beginning with one of the following sequences (Additional characters may follow these sequences.):
        [liste des six séquences disponible, de maximum deux caractères]
        man fopen
        
        Donc “parser” la chaîne de caractères consiste au bas mot à comparer deux char avec une liste de 6 séquences prédéfinies. C’est donc six comparaisons d’un entier 32 bits. Ni plus ni moins. Question performance je vois difficilement comment faire mieux. En fait je suppute que ce soit exactement les mêmes. D’ailleurs, des processeurs n bits peuvent-ils manipuler nativement des entités de m bits, m<n ? De toute façon, que les concepteurs du C aient choisi d’utiliser la chaîne de caractère devrait être une assez bonne indication que ça ne pose pas de problèmes de performances (ton argument sur Python se retourne contre toi là :p).
        
        Pour la question de la lisibilité, question d’habitude, probablement, donc débat de sourds, certainement. Je trouve mille fois plus lisible et plus agréable un code à deux lettres que de jouer avec des flag.
        
        [^] # Re: Les vrais ajouts
        
        Posté par barmic le 30 juillet 2011 à 14:33. Évalué à -1.
        
        D’ailleurs, des processeurs n bits peuvent-ils manipuler nativement des entités de m bits, m<n ?
        
        Par définition, la plus petite quantité de données adressable c'est le byte donc 8bits sur nos machines actuelles.
        
        Tu nous cite le manuel de fopen c'est bien moi je vais voir la doc python : http://docs.python.org/library/functions.html?highlight=open#open
        
        Le open admet les flags sont : r, w, a, +, u et U. On peut très bien avoir rw+U, le tout en unicode évidement. Il faut les parser caracyère par caractère parce que j'imagine que l'ordre n'est pas figé.
        
        D'ailleurs l'appelle système (qui ajoute beaucoup plus de contrôle sur l'utilisation des fichiers) utiliser des constantes.
        
        Enfin l'utilisation de constantes fait que tu n'a pas à parser l'argument tu t'en sert directement comme d'un tableau de booléens.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Les vrais ajouts
        
        Posté par Antoine le 30 juillet 2011 à 16:02. Évalué à 3.
        
        Le open admet les flags sont : r, w, a, +, u et U. On peut très bien avoir rw+U, le tout en unicode évidement. Il faut les parser caracyère par caractère parce que j'imagine que l'ordre n'est pas figé.
        
        Oui, et donc ? Tu penses que parser une chaîne de 4 caractères (fussent-ils unicode) est un problème ? Le coût est absolument minuscule, surtout par rapport au coût de l'ouverture du fichier proprement dite.
        
        Honnêtement tu as des notions de programmation bas niveau pour sortir ce genre d'âneries ?
        
        D'ailleurs l'appelle système (qui ajoute beaucoup plus de contrôle sur l'utilisation des fichiers) utiliser des constantes.
        
        Oui, et il est aussi plus bas niveau. Ce n'est pas un hasard.
        J'ajouterai que Python est un langage de haut niveau, et que Java prétend en être un.
        
        [^] # Re: Les vrais ajouts
        
        Posté par barmic le 30 juillet 2011 à 17:04. Évalué à 2.
        
        Le open admet les flags sont : r, w, a, +, u et U. On peut très bien avoir rw+U, le tout en unicode évidement. Il faut les parser caracyère par caractère parce que j'imagine que l'ordre n'est pas figé.
        
        Oui, et donc ? Tu penses que parser une chaîne de 4 caractères (fussent-ils unicode) est un problème ? Le coût est absolument minuscule, surtout par rapport au coût de l'ouverture du fichier proprement dite.
        
        Ça n'évolueras jamais ? Python n'ajouteras jamais de fonctionnalités à sa fonction open() ? Ce serais trop compliqué pour l'utilisateur ?
        
        Franchement, mis à par la taille des identifiants que reproche-tu à un code qui est ainsi :
        
        f=open('fichier', FFlag.read | FFlag.write)
        
        face à
        f=open('fichier', 'rw')
        
        Tu écris 20 caractères de plus, c'est si infernal pour toi ?
        Avec la première notation, des outils externes peuvent valider le code, ton IDE peut t'aider (un FFlag.<tab> te donne la liste des options), tu n'a aucun overhead aussi minime soit-il, …
        Alors oui ce n'est pas dans l'optique python qui cherche à en faire le maximum à l'exécution et un minimum avant, mais ce n'est pas pour ça que c'est mal.
        
        D'ailleurs l'appelle système (qui ajoute beaucoup plus de contrôle sur l'utilisation des fichiers) utiliser des constantes.
        
        Oui, et il est aussi plus bas niveau. Ce n'est pas un hasard.
        J'ajouterai que Python est un langage de haut niveau, et que Java prétend en être un.
        
        Il est surtout nettement plus précis dans son utilisation. Le open() python a très peu de possibilités face au open() système. Être haut niveau ne signifie pas être limité. Java se situe entre les deux.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Les vrais ajouts
        
        Posté par Antoine le 30 juillet 2011 à 17:56. Évalué à 4.
        
        Ça n'évolueras jamais ? Python n'ajouteras jamais de fonctionnalités à sa fonction open() ?
        
        Mais bien sûr qu'il y ajoute des fonctionnalités. Et d'ailleurs des arguments séparés ont été ajoutés pour certains d'entre eux. Mais les fonctionnalitéss de base restent accessibles simplement via la chaîne de flags, et cela suffit dans la majorité des cas.
        
        Désolé, mais je n'ai jamais vu un seul utilisateur de Python se plaindre de ce que open() produisait du code trop concis et qu'il faudrait plutôt des constantes à rallonge à la place. Et je ne connais personne qui préfère écrire O_CREAT | O_WRONLY plutôt que "wb".
        
        Tu écris 20 caractères de plus
        
        Dans l'exemple Java dont on parlait, c'était AMHA beaucoup plus de 20 caractères. Et avant de les écrire, il faut les mémoriser. Et après, il faut les relire. Comme c'est la philosophie adoptée par Java pour toutes ses APIs, cela produit du code hyper-verbeux.
        
        Enfin bon, libre à toi d'ignorer l'évidence.
        
        Il est surtout nettement plus précis dans son utilisation. Le open() python a très peu de possibilités face au open() système. Être haut niveau ne signifie pas être limité. Java se situe entre les deux.
        
        On commence à s'éloigner franchement du sujet, mais le open() de Python 3 a des possibilités que n'a pas le open() système, comme d'ouvrir un flux unicode (en choisissant l'encodage et le mode de traitement des erreurs), de faire une traduction automatique des caractères de fin de ligne, de choisir une stratégie de buffering, ou de wrapper un descripteur de fichier existant. C'est ce que j'appelle fournir une API haut niveau.
        
        Et, oui, si tu veux accéder aux flags bas niveau du open() système, tu peux utiliser os.open(), qui est une simple indirection vers l'appel système, et qui te produit un descripteur de fichier que tu peux réutiliser avec... open(). Donc tu n'es pas plus limité qu'en Java, et les cas d'usage courants sont largement plus lisibles et concis.
        
        [^] # Re: Les vrais ajouts
        
        Posté par barmic le 30 juillet 2011 à 19:57. Évalué à 0.
        
        Dans l'exemple Java dont on parlait, c'était AMHA beaucoup plus de 20 caractères. Et avant de les écrire, il faut les mémoriser. Et après, il faut les relire. Comme c'est la philosophie adoptée par Java pour toutes ses APIs, cela produit du code hyper-verbeux.
        
        Enfin bon, libre à toi d'ignorer l'évidence.
        
        L'évidence c'est qu'il faut connaître le langage dont on parle :)
        
        import static java.nio.file.StandardOpenOption.CREATE_NEW; import static java.nio.file.StandardOpenOption.SPARSE; Path p = Paths.get("/tmp", "file.txt"); OutputStream os = Files.newOutputStream(p, CREATE_NEW, SPARSE);
        
        A l'usage ça se fait très bien (au passage je ne connais aucun développeurs Java qui se plains d'avoir des identifiants trop longs ;)
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Les vrais ajouts
        
        Posté par Alex le 30 juillet 2011 à 20:41. Évalué à 2.
        
        A l'usage ça se fait très bien (au passage je ne connais aucun développeurs Java qui se plains d'avoir des identifiants trop longs ;)
        
        Ben en même temps, les gens qui ne se plaignent pas ne font pas ou plus de java ;)
        
        [^] # Re: Les vrais ajouts
        
        Posté par BB le 30 juillet 2011 à 16:21. Évalué à 2.
        
        Yep, je suis d’accord, Python est une outre bourrée remorquée par un escargot¹. Mais quand tu fais du Python, la vitesse d’ouverture d’un fichier est le dernier de tes soucis question performance. Dans le cas contraire, il y a un sérieux problème dans un programme qui veut ouvrir un fichier toutes les 10 ms. Je voulais juste remettre en doute l’affirmation qui dit que les chaînes de caractères sont moins performantes que les flags. Dans l’absolu je ne le crois pas. Ce servir d’un langage lent pour dire que les chaînes de caractères dans fopen sont longue à “parser”, c’est « juste pas très honnête » :p
        
        Par définition, la plus petite quantité de données adressable c'est le byte donc 8bits sur nos machines actuelles.
        
        Mais es-tu certain, par exemple si je fais :
        
        char a, b, c; a = 54; b = 18; c = a & b;
        
        qu’un processeur 32 ou 64 bits va manipuler de bout en bout des octets et pas plutôt des entités de 4 ou 8 octets en interne (avec le “zero-padding” qui va bien).
        
        Typiquement, pour des raisons de performances tu sais que :
        
        struct { char a; int b; };
        
        aura tendance à laisser un “trou” entre a et b, parce que « l’octet c’est bien gentil, mais les ordinateurs ont évolué depuis, et c’est pas forcément pertinent de redescendre à ce niveau là à l’heure actuelle ».
        
        De même au niveau du processeur je me demande si, quand on lui demande une opération sur un octet, il ne se contente pas simplement d’appliquer un masque sur une opération qu’il aura faite préalablement en 32 ou 64 bits.
        
        Enfin l'utilisation de constantes fait que tu n'a pas à parser l'argument tu t'en sert directement comme d'un tableau de booléens.
        
        ?!?
        Je ne sais pas trop ce que tu as voulu dire. Typiquement, pour le C ce que je fais dans ce cas là c’est de tester mon argument qui contient les flags, appelons le arg, avec des flags A, B, C, etc. pour cela je fais le test :
        
        arg & A; /* renvoie un nombre différent de 0, ou 0, pour savoir si le flag a été allumé, ou pas, respectivement. */
        
        C’est une opération bit-à-bit et un test par flag, si tu as 8 flag ça tient dans un octet. Partant de là, le fopen du C ne doit pas être moins performant que son équivalent avec flag : 6 modes possibles, 6 tests d’égalité à faire, sur un octet. Effectivement si tu t’amuses à ne plus définir l’ordre des caractères, ou à augmenter la taille de la chaîne, alors je veux bien croire qu’il vaut mieux utiliser des flags.
        
        ¹ J’utilise ce langage tous les jours et je l’adore. Même si ça ne se voit pas.
        
        PS : j’en profite de t’avoir sous la main pour un commentaire sur markdown. tralala_: poum, où « _ » est une espace insécable, perturbe l’analyse de *lala* pour le mettre en italique. Comme *ici* : snif.
        
        [^] # Re: Les vrais ajouts
        
        Posté par BB le 30 juillet 2011 à 17:30. Évalué à 1.
        
        Désolé, à propos du PS, je te confonds toujours avec Bruno Michel -_-
        
        [^] # Re: Les vrais ajouts
        
        Posté par barmic le 30 juillet 2011 à 18:11. Évalué à 0.
        
        Mais quand tu fais du Python, la vitesse d’ouverture d’un fichier est le dernier de tes soucis question performance.
        
        Je m'en balance de python. La remarque a était faite contre Java et porte sur l'organisation de ce genre de code.
        
        Les pythonistes font ce qu'ils veulent je n'aimerais pas plus leur langage pour autant (je l'utilise et je comprends ses principes mais je n'aime pas beaucoup) :)
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Les vrais ajouts
        
        Posté par Antoine le 30 juillet 2011 à 15:54. Évalué à 2.
        
        C'est faux, si tu n'ouvre ton fichier que dans des cas précis, il va falloir que tu entre dans ce cas précis pour arriver à le détecter.
        
        C'est à ça que servent les tests unitaires. Si tu n'as pas de tests pour cette partie du code, il y a certainement d'autres bugs plus retors qui s'y baladent, et qui ne seront pas détectés par une phase de compilation.
        
        Chercher à être compacte à l'extrême n'a pas de sens.
        
        C'est toi qui vois des extrêmes partout. J'ai parlé de compromis. Un code compact est important, à la fois pour la lisibilité (un code long et verbeux est beaucoup plus pénible à lire) et la facilité d'écriture.
        
        Le mode U ou u n'a rien d'intuitif.
        
        Il ne serait pas plus intuitif avec une option de cinquante caractères dédiée. Dans les deux cas, il faut lire la doc une première fois pour savoir ce que ça fait.
        
        Contrairement à ce que semblent penser les développeurs Java, nommer les choses de façon verbeuse ne remplace pas une documentation.
        
        Chercher à gagner 5 à 10 caractères en perdant en lisibilité, en performance et en fiabilité, ça n'a pas de sens.
        
        On n'y perd pas, justement, sauf dans une vision naïve de la programmation où la compilation suffit à détecter les bugs et où gagner une fraction de microseconde à l'ouverture d'un fichier est important.
        
        [^] # Re: Les vrais ajouts
        
        Posté par pasScott pasForstall le 30 juillet 2011 à 21:57. Évalué à -1.
        
        Donc sous pretexte que certains bugs sont runtimes, ils faut ajouter a la liste des bugs compile time?
        Les tests unitaires, c'est certes tres pratique, mais leur gros probleme, c'est qu'ils sont justement unitaires.
        Tu peux pas tout tester avec des tests unitaires.
        Quand tu vas commencer a integrer des classes entre elles, et toutes tes classes qui marchaient tres bien toutes seules vont commencer a ne plus marcher.
        
        J'ai du mal a comprendre la logique en fait, une approche permet de trouver des bugs a coup sur tres tot, avant meme que le dev ait commite.
        Quelle est le probleme avec au juste? Que READ c'est plus long a taper que r?!?! Vraiement?
        
        Contrairement à ce que semblent penser les développeurs Java, nommer les choses de façon verbeuse ne remplace pas une documentation.
        
        Ca remplace pas la doc, mais ca permet de comprendre plus facilement (universal_newline est achement plus comprehensible que u).
        
        On n'y perd pas, justement, sauf dans une vision naïve de la programmation où la compilation suffit à détecter les bugs et où gagner une fraction de microseconde à l'ouverture d'un fichier est important.
        
        Et penser que les tests unitaires vont couvrir 100% des chemins, c'est pas naif?
        
        If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
        
        [^] # Re: Les vrais ajouts
        
        Posté par Lucky Seven le 01 août 2011 à 16:08. Évalué à -1.
        
        Et penser que les tests unitaires vont couvrir 100% des chemins, c'est pas naif?
        
        Si tu les écrits correctement, pourquoi ça ne serait pas le cas ?
        
        [^] # Re: Les vrais ajouts
        
        Posté par barmic le 01 août 2011 à 19:36. Évalué à 3.
        
        Et penser que les tests unitaires vont couvrir 100% des chemins, c'est pas naif?
        
        Si tu les écrits correctement, pourquoi ça ne serait pas le cas ?
        
        Parce qu'il existe une infinité de chemin ? Que dès que le programme deviens un minimum évolué la couverture de branche deviens déjà très compliquée ?
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Les vrais ajouts
        
        Posté par Lucky Seven le 02 août 2011 à 10:05. Évalué à 0.
        
        Parce qu'il existe une infinité de chemin ? Que dès que le programme deviens un minimum évolué la couverture de branche deviens déjà très compliquée ?
        
        Désolé, mal lu.
        Il existe une infinité de chemin, mais je pensais plutôt à la couverture de l'entièreté du code.
        
        [^] # Re: Les vrais ajouts
        
        Posté par Antoine le 01 août 2011 à 17:20. Évalué à 2.
        
        Les tests unitaires, c'est certes tres pratique, mais leur gros probleme, c'est qu'ils sont justement unitaires.
        
        Tu peux ajouter des tests fonctionnels, ce n'est pas exclusif.
        
        J'ai du mal a comprendre la logique en fait, une approche permet de trouver des bugs a coup sur tres tot, avant meme que le dev ait commite.
        Quelle est le probleme avec au juste?
        
        Dans l'absolu, aucun. Le problème c'est avec la version Java de cette approche :
        
        il y a une phase de compilation explicite
        
        la verbosité du langage est largement augmentée (noms d'identifiants à rallonge, pas d'inférence de type...)
        
        Je suis bien d'accord que ce n'est pas inhérent à l'approche décrite, mais on parle bien de Java, pas d'un langage idéal.
        
        Ca remplace pas la doc, mais ca permet de comprendre plus facilement (universal_newline est achement plus comprehensible que u).
        
        open() étant une fonction super utilisée, je ne vois pas pourquoi le programmeur lambda ne finirait pas par reconnaître les trois ou quatre options d'ouverture possibles.
        
        Encore une fois, c'est comme ls. Tu as le droit de préférer listDirectoryContents --verbose-listing, mais je crois que la plupart voudront continuer à utiliser ls -l.
        
        Et penser que les tests unitaires vont couvrir 100% des chemins, c'est pas naif?
        
        Si, c'est naïf (ou, plus exactement, ce qui est naïf est de croire que 100% de couverture permet de détecter tous les bugs). N'empêche que les tests permettent de détecter et de prévenir des bugs beaucoup plus "intéressants" (lire : tordus) que la compilation.
        
        [^] # Re: Les vrais ajouts
        
        Posté par pasScott pasForstall le 01 août 2011 à 18:56. Évalué à -2.
        
        Ok, donc laisse moi reposer ma question:
        
        Donc sous pretexte que certains bugs sont runtimes, ils faut ajouter a la liste des bugs compile time?
        
        If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
        
        [^] # Re: Les vrais ajouts
        
        Posté par pasScott pasForstall le 30 juillet 2011 à 06:39. Évalué à 0.
        
        C'est pas parce que tu te rendras qu'au runtime qu'ouvrir ton ficher de cache en lecture seule, c'etait une mauvaise idée, qu'il est inutile de s'assurer a la compile que t'essayes pas d'utiliser un flag qui n'existe pas a cause d'une faute de frappe.
        Surtout quand ton API est orientée stream plutôt que fichier et que des sous classes entre en jeu.
        
        Et ça te permet d'avoir des flags un peu plus compréhensible pour le developeur (rb j'ai aucune idée de ce que ça veut dire).
        
        If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
        
        [^] # Re: Les vrais ajouts
        
        Posté par Antoine le 30 juillet 2011 à 09:15. Évalué à 2.
        
        C'est pas parce que tu te rendras qu'au runtime qu'ouvrir ton ficher de cache en lecture seule, c'etait une mauvaise idée, qu'il est inutile de s'assurer a la compile que t'essayes pas d'utiliser un flag qui n'existe pas a cause d'une faute de frappe.
        
        Heu, Java invente ses propres problèmes à résoudre.
        Autant c'est facile de faire une faute de frappe avec StandardOpenOption.CREATE_NEW (c'est bien ça ?), autant avec "wb" il faut le vouloir.
        
        Et ça te permet d'avoir des flags un peu plus compréhensible pour le developeur (rb j'ai aucune idée de ce que ça veut dire).
        
        Ben, vu 1) la simplicité des chaînes de flags à passer à open(), 2) que ce sont les mêmes dans beaucoup de langages (cf. le fopen() du C), et 3) qu'ouvrir un fichier est une opération courante, ça se retient très très vite.
        
        Tu peux aussi m'expliquer qu'il faudrait remplacer ls par listDirectoryContents qui est vachement plus lisible.
        
        (pour mémoire : "r" pour read et "b" pour binary)
        
        Surtout quand ton API est orientée stream plutôt que fichier et que des sous classes entre en jeu.
        
        Encore une conception Javaesque. Tu peux très bien avoir une pile de classes orientée stream, comme dans Python 3, tout en cachant le tout derrière une fonction open() bien commode.
        
        cf. http://docs.python.org/py3k/library/io.html
        
        [^] # Re: Les vrais ajouts
        
        Posté par barmic le 30 juillet 2011 à 11:47. Évalué à 1.
        
        (pour mémoire : "r" pour read et "b" pour binary)
        
        Et "u" pour ?
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Les vrais ajouts
        
        Posté par Jean B le 30 juillet 2011 à 12:13. Évalué à 1.
        
        Et "u" pour ?
        
        U pour Universal newline support qui remplace de manière transparente les "\r\n" et les "\r" par des "\n".
        
        [^] # Re: Les vrais ajouts
        
        Posté par pasScott pasForstall le 30 juillet 2011 à 12:51. Évalué à -3.
        
        Je risque pas de faire de faute frappe. L'ide complete, et meme s'il complete pas, le compilo me gueulera dessus.
        
        Ben, vu 1) la simplicité des chaînes de flags à passer à open(), 2) que ce sont les mêmes dans beaucoup de langages (cf. le fopen() du C), et 3) qu'ouvrir un fichier est une opération courante, ça se retient très très vite.
        
        Et si tu tapes z a la place de w, par exemple (idee a la con), qu'est ce qu'il se passe?
        
        Encore une conception Javaesque. Tu peux très bien avoir une pile de classes orientée stream, comme dans Python 3, tout en cachant le tout derrière une fonction open() bien commode.
        
        ben c'est pas trop la question, plutot comment eviter des erreurs (genre ouvrir un flux de sortie en lecture) en utilisant uniquement des strings?
        
        If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
        
        [^] # Re: Les vrais ajouts
        
        Posté par Antoine le 30 juillet 2011 à 16:08. Évalué à 3.
        
        Je risque pas de faire de faute frappe. L'ide complete, et meme s'il complete pas, le compilo me gueulera dessus.
        
        Eh bien, dans ce cas, on peut imaginer que l'IDE soit également capable d'indiquer les chaînes valides pour la fonction open().
        
        Et si tu tapes z a la place de w, par exemple (idee a la con), qu'est ce qu'il se passe?
        
        Le même genre de choses que si tu te gourres d'une lettre dans le nom d'un fichier passé à la même fonction (*). Je ne comprends pas trop ce genre d'arguments, la qualité principale que tu cherches dans un langage de programmation est d'éviter les fautes de frappe ? Il y a des choses plus importantes...
        
        (*) en pratique:
        
        >>> open("LICENSE", "z") Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: mode string must begin with one of 'r', 'w', 'a' or 'U', not 'z'
        
        [^] # Re: Les vrais ajouts
        
        Posté par pasScott pasForstall le 30 juillet 2011 à 22:03. Évalué à 1.
        
        Eh bien, dans ce cas, on peut imaginer que l'IDE soit également capable d'indiquer les chaînes valides pour la fonction open().
        
        Heuuu, non. Ton ide ne peut pas evaluer des parametres.
        Function readfile(mode)
        Open(file, mode)
        // faire qq chose
        End
        
        Tu ide va avoir du mal a verifier ce qu'il se passe la.
        
        Le même genre de choses que si tu te gourres d'une lettre dans le nom d'un fichier passé à la même fonction (*). Je ne comprends pas trop ce genre d'arguments, la qualité principale que tu cherches dans un langage de programmation est d'éviter les fautes de frappe ? Il y a des choses plus importantes...
        
        Une des qualites d'une API (je vois pas ce que le langage vient faire la) c'est de m'eviter par design de faire des erreurs betes qui n'ont pas de sens, comme par exemple ouvrir un fichier en mode z.
        
        If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
        
        [^] # Re: Les vrais ajouts
        
        Posté par Jean B le 30 juillet 2011 à 23:19. Évalué à 0.
        
        Mouais... quand on veut on peut:
        
        Path p = Paths.get("/tmp", "file.txt"); OutputStream os = Files.newOutputStream(p, 1337);
        
        [^] # Re: Les vrais ajouts
        
        Posté par ckyl le 31 juillet 2011 à 11:04. Évalué à 5.
        
        Comme dans toute discussion sur Java des avis et commentaires très fondés/pertinents :p
        
        Les flags c'est des varargs typés sur un enum. Vu que c'est pas un bitfield tu vas avoir du mal à passer 1337 paramètre... Après ça n’empêche pas de passer des combinaisons de flags débiles qui te lèveront une Runtime, mais pourquoi se priver d'une vérification possible et éviter de faire une exception pour une fonction particulière ?
        
        Tu peux faire une réponse courte, après les 50 commentaires particulièrement utiles sur Files.newOutputStream() il reste au moins 200 autres fonctions à discuter ;)
        
        [^] # Re: Les vrais ajouts
        
        Posté par ckyl le 30 juillet 2011 à 10:50. Évalué à 4.
        
        Le problème c'est qu'on peut faire un peu plus qu'un "rb". Et quand tu écris ou étends une nouvelle version d'un FileSystem tu peux lui ajouter les options qui vont bien.
        
        http://download.oracle.com/javase/7/docs/api/java/nio/file/StandardOpenOption.html
        
        Et c'est dingue open(2) n'utilises pas une string pour passser les flags et le mode !
        
        D'une manière générale utiliser des types plutôt que tout foutre dans des String. Les strings sont l'ennemie du refactoring et de l'identification de code. Après si tu n'aimes pas le typage statique fort, Java n'est simplement pas pour toi.
        
        [^] # Re: Les vrais ajouts
        
        Posté par pasScott pasForstall le 30 juillet 2011 à 02:50. Évalué à 0.
        
        (le StandardOpenOption.BIDULE étant particulièrement lourd, tout de même)
        
        D'ou les import static de java 6 qui le transforme en BIDULE.
        :)
        
        If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
        
        [^] # Re: Les vrais ajouts
        
        Posté par ckyl le 30 juillet 2011 à 10:34. Évalué à 3.
        
        Effectivement quand on lit l'exemple on peut se dire ça. Mais j'applique un principe assez désuet de nos jour qui est de supposer que les gens qui ont écrit l'API ont une chance d'être moins con que moi et d'avoir plus réfléchi au problème. Du coup on peut se dire qu'il y a une raison pour avoir fait ce choix (même si on peut être en désaccord).
        
        Quand tu regardes la tête de l'API dans sa globalité tu comprends pourquoi. Simplement par ce que tout le bousin est conçu pour être générique. Tu peux implémenter ton propre provider de FileSystem et de tout les objet qui vont avec. Et ça va être très pratique.
        
        Si tu veux absolument une notation courte similaire à fopen(3) pour le cas général, le wrapper doit s'écrire en 5 lignes et basta.
    - [^] # Re: Les vrais ajouts
      
      Posté par zebra3 le 29 juillet 2011 à 16:01. Évalué à 6.
      
      C'est-à-dire que comme Perl 6 doit bientôt sortir, les gens de Sun ont voulu démontrer que Java pouvait être le langage universel.
      
      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# Très bon

Posté par reno le 29 juillet 2011 à 09:47. Évalué à 10.

Pas réveillé, je lis la liste des améliorations en me disant "Tiens? C'est bien tout ça." jusqu'à ce que j'arrive à la fin de ton journal.
Bref, je me suis bien fait avoir, bravo!

Juste une question: c'est quoi les "safe navigation operator"?
- [^] # Re: Très bon
  
  Posté par Frank-N-Furter le 29 juillet 2011 à 10:15. Évalué à 2.
  
  C'est l'équivalant du capitaine de soirée http://www.youtube.com/watch?v=qcXlVCCUfjY
  
  Depending on the time of day, the French go either way.
- [^] # Re: Très bon
  
  Posté par ckyl le 29 juillet 2011 à 10:26. Évalué à 10.
  Sans:
```
o1 = foo()
if (o1 != null) {
  o2 = o1.bar()
  if (o2 != null) {
    o3 = o2.toto()
    if (o3 != null) {
      o3.print()
    }
  }
}
```
  Avec:
```
foo()?.bar()?.toto()?.print()
```
  Ca peut être de très utile à trompeur selon les cas.
  - [^] # Re: Très bon
    
    Posté par hsyl20 (site web personnel) le 29 juillet 2011 à 18:04. Évalué à 1.
    Pour le fun, si on voulait faire la même chose en Scala :
```
scala> implicit def pouet[A](a:A) = new { def !![B<:AnyRef](f:A=>B):B = if (a != null) f(a) else null.asInstanceOf[B] }
pouet: [A](a: A)java.lang.Object{def !![B <: AnyRef](f: (A) => B): B}

scala> "lapin" !! (_.toUpperCase) !! (_ drop 2)
res21: String = PIN

scala> "lapin" !! (_.toUpperCase) !! (_ drop 2) !! (s => if (s.contains("grut")) "youpy" else null) !! (_.reverse)
res22: String = null

scala> "lapin" !! (_.toUpperCase) !! (_ drop 2) !! (s => if (s.contains("IN")) "youpy" else null) !! (_.reverse)
res23: String = ypuoy
```
```
..
..
..
```
    Mais en général on n'utilise pas "null" en Scala, on utilise le type Option :
```
scala> Some("lapin") map (_.toUpperCase) map (_ drop 2) flatMap (s => if (s.contains("IN")) Some("youpy") else None) map (_.reverse)
res24: Option[String] = Some(ypuoy)

scala> Some("lapin") map (_.toUpperCase) map (_ drop 2) flatMap (s => if (s.contains("grut")) Some("youpy") else None) map (_.reverse)
res25: Option[String] = None
```
    - [^] # Re: Très bon
      
      Posté par pasScott pasForstall le 29 juillet 2011 à 19:12. Évalué à 1.
      
      Et en objective c
      [[[O1 bar] foo] print].
      ou la meme version en dot notation si vous aimez pas les imbrications.
      
      If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
- [^] # Re: Très bon
  
  Posté par TImaniac (site web personnel) le 29 juillet 2011 à 10:27. Évalué à 7.
  
  C'est un opérateur pour éviter de se manger des nullexception de manière lisible :
  streetName = user?.address?.street
  
  Ca évite d'écrire :
  if(user != null && user.address != null)
  streetName = user.address.street
  - [^] # Re: Très bon
    
    Posté par calvin2001 le 29 juillet 2011 à 14:35. Évalué à 2.
    
    Les safe-navigators existent en Groovy, et c'est la même syntaxe que celle présentée ci-dessus.
    
    Une des améliorations de Java 7 est l'ajout d'un nouveau bytecode, InvokeDynamic, qui devrait améliorer les perfs des langages basés sur la JVM, tels que Groovy, Scala, JRuby et cie.
  - [^] # Re: Très bon
    
    Posté par Antoine le 29 juillet 2011 à 15:46. Évalué à -1.
    
    Et donc, ça avale automatiquement l'exception sans rien faire?
    
    Ça me rappelle le "@" de PHP : tout le monde va se mettre à l'utiliser histoire de ne pas passer trop de temps à débugger les problèmes sous-jacents.
    - [^] # Re: Très bon
      
      Posté par Jean B le 29 juillet 2011 à 16:00. Évalué à 8.
      
      Quelle exception ? Si un des élément de la chaine est null alors elle s'interrompt et le resultat est null. C'est "juste" du sucre syntaxique, mais ça simplifie énormément la vie.
  - [^] # Re: Très bon
    
    Posté par barmic le 29 juillet 2011 à 23:09. Évalué à 2.
    Sauf que généralement derrière tu as une gestion de l'erreur ou du problème. C'est relativement rare que ce ne soit pas un problème ou que tu n'ai pas quelque chose à faire à la place.
    
    Je ne vois pas de grande différence entre :
```
Objects.equals(a.a, b.a);
```
    et
```
a.a.equals(b?.a);
```
    Sauf que la première je l'utilise en Java 6 sans problème :)
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Ca dénonce grave

Posté par Pierre Tramonson le 29 juillet 2011 à 12:48. Évalué à -2.

Bon, on va rentrer dans le troll :)

Inférence de type des variables
Super, utiliser var toto plutôt que int toto. On sait pas ce qu'on manipule, comme en VB \o/

arguments optionnels
ça peut servir en effet. Mais les cas où j'ai eu à faire de la surcharge de méthode pour gérer un nb d'arguments variable sont assez rares.
Si on se retrouve à faire une brouette de surcharges, c'est que quelque chose ne va pas dans la conception.

arguments nommés
Normalement, un simple ctrl-espace dans ton IDE préféré te sort la liste des arguments d'une fonction, avec leur type. Ca peut servir d'ajouter les named arguments mais on reprocherait à Java d'être trop verbeux :p

méthodes d'extension
Je ne vois pas vraiment d'utilisation IRL, ça peut être aisément traité avec un simple héritage/surcharge de méthode.

lambdas expression
Intérêt hormis pour faire un truc du genre de Linq ?
Ceci dit : http://openjdk.java.net/projects/lambda/

arbres d'expression
idem, il y a plein de beaux articles dans des blogs techniques, mais est-ce vraiment utilisé sur des projets C# ?

langage de requêtage intégré
ça c'est dommage en effet

Safe navigation operator
Je conviens que cela pourrait être pratique et améliorer la lisibilité du code.

références non nulles
heu oui, dans quel cas ?

En gros ce que tu reproches au langage Java 7 c'est de ne pas être C# 3 avec les lambdas et Linq, non ?
- [^] # Re: Ca dénonce grave
  
  Posté par devnewton 🍺 (site web personnel) le 29 juillet 2011 à 14:03. Évalué à 2.
  
  Est-ce que Scala n'a pas déjà toutes ces "features"?
  
  Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
  - [^] # Re: Ca dénonce grave
    
    Posté par hsyl20 (site web personnel) le 29 juillet 2011 à 14:39. Évalué à 1.
    
    Si.
- [^] # Re: Ca dénonce grave
  
  Posté par snt le 29 juillet 2011 à 14:07. Évalué à 3.
  Un peu plus sérieusement, les 3 qui m'interessent au quotidien, c'est :
  - les lambdas
  - Safe navigation operator
  - les références non nulles
  
  Les lambdas, c'est quand meme un gros gain d'expressivité. C# le fait.
  
  Le safe navigation operator, c'est l'application du DRY. Et en plus ça indique que le développeur a explictement pensé au cas où les données retournées sont nulles. C# ne l'a pas. Groovy l'a.
  
  Enfin les références non nulles, c'est plus un avantage pour la fiabilité du programme. C# ne le fait pas, mais d'autres langages ont des sécurités plus ou moins équivalentes ( http://confluence.jetbrains.net/display/Kotlin/Null-safety ).
  
  Si je prends ton lien et que je fais une comparaison Java 7/"SuperJava", j'obtiens ça :
  
  Avant :
```
Collections.sort(people, new Comparator<Person>() {
    public int compare(Person x, Person y) {
        String rueX = "" ;
        String rueY = "" ;
        if (x!=null && x.adress!=null && x.adress.street != null)
            rueX = x.adress.street.name ;
        if (y!=null && y.adress!=null && y.adress.street != null)
            rueY = y.adress.street.name ;
        return rueX.compareTo(rueY);
    }
});
```
  Après :
```
Collections.sortBy(people, #{ p -> p.?adress.?street.?name });
```
  C'est caricatural, mais c'est quand meme beau de rever.
- [^] # Re: Ca dénonce grave
  
  Posté par BFG le 29 juillet 2011 à 14:40. Évalué à 3.
  Inférence de type des variables
  
  Super, utiliser var toto plutôt que int toto. On sait pas ce qu'on manipule, comme en VB \o/
  
  Personne n'a dit que ça devait être utilisé tout le temps. C'est plutôt utile dans le cas de variables très locales avec des types génériques. Prenons par exemple :
```
std::list<std::list<std::string> >::iterator it = stringlist.begin();
while (it != stringlist.end()) {
    // ...
}
// et
auto it = stringlist.begin();
while (it != stringlist.end()) {
    // ...
}
```
  arguments nommés
  
  Normalement, un simple ctrl-espace dans ton IDE préféré te sort la liste des arguments d'une fonction, avec leur type. Ca peut servir d'ajouter les named arguments mais on reprocherait à Java d'être trop verbeux :p
  
  Le code n'est pas qu'écrit, il est aussi lu.
  
  Safe navigation operator
  
  Je conviens que cela pourrait être pratique et améliorer la lisibilité du code.
  
  Qu'est ce qui arrive si une expression est nulle ?
  
  références non nulles
  
  heu oui, dans quel cas ?
  
  C'est un peu comme le "Safe navigation operator", sauf que c'est à la compilation, ce qui le rend vraiment plus sûr.
- [^] # Re: Ca dénonce grave
  
  Posté par TImaniac (site web personnel) le 29 juillet 2011 à 17:08. Évalué à 1.
  Bon, on va rentrer dans le troll :)
  
  J'aime le troll =)
  
  On sait pas ce qu'on manipule, comme en VB \o/
  
  Le compilateur, lui il sait, contrairement au compilateur VB. Et l'IDE aussi, donc toi aussi :-p
  
  méthodes d'extension Je ne vois pas vraiment d'utilisation IRL, ça peut être aisément traité avec un simple héritage/surcharge de méthode.
  
  Ben justement, ca permet d'étendre des types dont tu ne peux pas hériter ou dont tu n'as pas envie d'hériter. T'as jamais eu envie d'ajouter une méthode à la classe object et que toutes les classes en profite ?
  
  Intérêt hormis pour faire un truc du genre de Linq ?
  
  Ca sert à passer du code simplement en paramètre, exemple avec 2 utilisations de callback :
```
...
doStuffAsync(42, res => Console.WriteLine(res));
...

public void doStuffAsync(int p1, Action<int> callback)
{
    ThreadPool.QueueuserWorkItem(() => {
       var res = doHardWorkOnP1(p1);
       callback(p1);
    });
}
```
  idem, il y a plein de beaux articles dans des blogs techniques, mais est-ce vraiment utilisé sur des projets C# ?
  
  Oui, pleins de projets l'utilise. ca permet par exemple d'écrire quelque chose comme ca :
```
string int ValeurMetier{get;set;}
...
RaisePropertyChanged(m => m.ValeurMetier);
...
```
  Et voilà, j'ai une méthode générique RaisePropertyChanged qui va lever un événément indiquant que la propriété ValeurMetier a changé. Sans l'arbre d'expression, t'aurais dû écrire quelque chose comme ca :
```
RaisePropertyChanged("ValeurMetier");
```
  Pas de typage : erreur possible, pas de refactoring, etc.
  
  Sinon l'arbre d'expression c'est largement utilisé en interne par les compilos/libs .NET : Linq s'appui intégralement dessus, les languages dynamiques comme IronPython et IronRuby également.
# Le commentaire du vendredi qui résume tout

Posté par Maclag le 29 juillet 2011 à 17:15. Évalué à 4.

Avant, Java était détesté de tout le monde sauf ceux qui ne savent pas coder correctement avec un autre langage.

Avec Java7, Jave sera détesté de tout le monde sauf ceux qui ne savent pas coder correctement avec un autre langage, mais encore plus.

Bon week-end!

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.