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 . É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. . É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 . É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 . É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 . É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 . É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 . Évalué à 1.
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 . É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 . Évalué à 1.
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).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 . É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 . Évalué à 10.
Java SE (parce que JEE n'évolue pas en même temps donc parler des entreprises...) 7 apporte :
null
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 . É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 . É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 . É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 . É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 . Évalué à 10.
Avec ce qu'ils ont sur la table, ce n'est pas très pratique, si ?
[^] # Re: Les vrais ajouts
Posté par pasScott pasForstall . É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 . É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) . É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.
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) . É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) . É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) . É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) . É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 . Évalué à 4.
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) . É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 :
==
)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 :
Autant Java a plein d'avantagesAutant la jvm a plein d'avantages, autant java est pour moi un très mauvais langage.
[^] # Re: Les vrais ajouts
Posté par ckyl . É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 . Évalué à 4.
quand je vois passer des
-Djava.util.Arrays.useLegacyMergeSort=true
je me dis que c'est ratai.
[^] # Re: Les vrais ajouts
Posté par ckyl . É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 . Évalué à 2.
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 . É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 . Évalué à 3.
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) . É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:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Les vrais ajouts
Posté par barmic . Évalué à 2.
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) . É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 . Évalué à 1.
Ca se tient. Ou un objet spécial qui retourne toujours faux et ne fait rien.
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) . É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 . É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 . Évalué à -1.
Parce que c'est ce qui est le plus logique ?
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 . Évalué à 2.
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 . Évalué à 1.
On ne doit pas avoir la même définition de safe.
[^] # Re: Les vrais ajouts
Posté par devnewton 🍺 (site web personnel) . É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 . É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 desString
, 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) deString
: un pool deString
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 pasnew 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) . É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
vrairaison 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 . Évalué à 3.
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 avecequals
, et String ne fait pas exception à la règle.Utiliser
==
est bien plus rapide que d'utiliserequals
. 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.==
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.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) . Évalué à 2.
C'est surtout qu'en réalité c'est pas du tout la même chose.
Mais justement,
==
ne fonctionne pas dans ce casLe 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 . Évalué à 2.
Oui, donc par défaut, c'est equals pour les objet. Ceux qui utilisent == pour les objets le font pour de bonnes raisons.
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.
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 . Évalué à 1.
Pardon, faux-négatifs, bien sûr
[^] # Re: Les vrais ajouts
Posté par CrEv (site web personnel) . É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 . Évalué à 1.
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.
Avec plaisir
[^] # Re: Les vrais ajouts
Posté par barmic . Évalué à 2.
Tu n'a jamais vu de fonctions
equals()
ainsi ?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 . Évalué à 1.
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 . Évalué à 2.
Ç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 :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 . É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 . Évalué à 1.
Quelle est la logique dans le code suivant:
Note: == peut avoir été surcharge.
Ou pas.
Et last but not least, que fait le code suivant:
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 . Évalué à 3.
Et si dans ton exemple on remplace '==' par '.equals()' on peut aussi dire
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 . É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 . É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 . É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 quex == 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 . Évalué à 6.
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 . É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 . Évalué à 2.
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 . É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).
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 . Évalué à 2.
Non, relis. Je veux bien croire que mes messages sont concis, mais je n'ai pas dit cela.
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 . Évalué à 2.
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 . É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 . É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 :
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)
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 . É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?
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.
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.
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) . É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 . É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 . É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 . É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) . É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 . É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). 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 ;)
Les cas où ce n'est pas une bonne idée sont tordus, théoriques et la faute viens de code pourris.
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 . Évalué à 2.
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 . Évalué à -1.
Qu'est ce donc ?
J'ai vu deux solutions :
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
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 . Évalué à 4.
Un exemple fictif facilement compréhensible :
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) . É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 . Évalué à 3.
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 . É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 . É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 . Évalué à 3.
Toute la beauté de Java condensée (?) en quelques caractères.
[^] # Re: Les vrais ajouts
Posté par ckyl . Évalué à 2.
Ou alors si utilises la vraie API et pas celle supposée dans un article de 2008:
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 . Évalué à 10.
C'est vrai que c'est beaucoup plus beau, au temps pour moi.
[^] # Re: Les vrais ajouts
Posté par ckyl . Évalué à 2.
Histoire d'être constructif tu reproches quoi ?
[^] # Re: Les vrais ajouts
Posté par Alex . Évalué à 4.
L'utilisation de 4 classes, ou la verbosité bien lourde
[^] # Re: Les vrais ajouts
Posté par barmic . É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 . É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 . Évalué à 1.
La verbosité par rapport à un truc du genre:
(le StandardOpenOption.BIDULE étant particulièrement lourd, tout de même)
[^] # Re: Les vrais ajouts
Posté par Alex . É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++
[^] # Re: Les vrais ajouts
Posté par Antoine . É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 . É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 . Évalué à 1.
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.
(*)
On va gagner une fraction de microseconde à chaque ouverture de fichier, chouette.
[^] # Re: Les vrais ajouts
Posté par barmic . Évalué à 4.
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.
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 . Évalué à 2.
Pour ce que ça vaut :
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 . Évalué à -1.
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
etU
. On peut très bien avoirrw+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 . Évalué à 3.
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 ?
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 . Évalué à 2.
Ç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 :
face à
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.
Il est surtout nettement plus précis dans son utilisation. Le
open()
python a très peu de possibilités face auopen()
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 . Évalué à 4.
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 écrireO_CREAT | O_WRONLY
plutôt que"wb"
.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.
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 . Évalué à 0.
L'évidence c'est qu'il faut connaître le langage dont on parle :)
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 . Évalué à 2.
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 . É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
Mais es-tu certain, par exemple si je fais :
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 :
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.
?!?
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 flagsA
,B
,C
, etc. pour cela je fais le test :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 . Évalué à 1.
Désolé, à propos du PS, je te confonds toujours avec Bruno Michel -_-
[^] # Re: Les vrais ajouts
Posté par barmic . Évalué à 0.
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 . Évalué à 2.
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.
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.
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.
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 . É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?
Ca remplace pas la doc, mais ca permet de comprendre plus facilement (universal_newline est achement plus comprehensible que u).
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 . Évalué à -1.
Si tu les écrits correctement, pourquoi ça ne serait pas le cas ?
[^] # Re: Les vrais ajouts
Posté par barmic . Évalué à 3.
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 . Évalué à 0.
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 . Évalué à 2.
Tu peux ajouter des tests fonctionnels, ce n'est pas exclusif.
Dans l'absolu, aucun. Le problème c'est avec la version Java de cette approche :
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.
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érerlistDirectoryContents --verbose-listing
, mais je crois que la plupart voudront continuer à utiliserls -l
.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 . Évalué à -2.
Ok, donc laisse moi reposer ma question:
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 . É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 . Évalué à 2.
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.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
parlistDirectoryContents
qui est vachement plus lisible.(pour mémoire : "r" pour read et "b" pour binary)
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 . Évalué à 1.
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 . Évalué à 1.
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 . Évalué à -3.
Je risque pas de faire de faute frappe. L'ide complete, et meme s'il complete pas, le compilo me gueulera dessus.
Et si tu tapes z a la place de w, par exemple (idee a la con), qu'est ce qu'il se passe?
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 . Évalué à 3.
Eh bien, dans ce cas, on peut imaginer que l'IDE soit également capable d'indiquer les chaînes valides pour la fonction
open()
.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:
[^] # Re: Les vrais ajouts
Posté par pasScott pasForstall . Évalué à 1.
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.
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 . Évalué à 0.
Mouais... quand on veut on peut:
[^] # Re: Les vrais ajouts
Posté par ckyl . É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 . É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 . Évalué à 0.
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 . É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 . É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 . É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 . É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 . Évalué à 10.
Sans:
Avec:
Ca peut être de très utile à trompeur selon les cas.
[^] # Re: Très bon
Posté par hsyl20 (site web personnel) . Évalué à 1.
Pour le fun, si on voulait faire la même chose en Scala :
Mais en général on n'utilise pas "null" en Scala, on utilise le type Option :
[^] # Re: Très bon
Posté par pasScott pasForstall . É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) . É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 . É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 . É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 . É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 . É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 :
et
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 . É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) . É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) . Évalué à 1.
Si.
[^] # Re: Ca dénonce grave
Posté par snt . É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 :
Après :
C'est caricatural, mais c'est quand meme beau de rever.
[^] # Re: Ca dénonce grave
Posté par BFG . Évalué à 3.
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 :
Le code n'est pas qu'écrit, il est aussi lu.
Qu'est ce qui arrive si une expression est nulle ?
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) . Évalué à 1.
J'aime le troll =)
Le compilateur, lui il sait, contrairement au compilateur VB. Et l'IDE aussi, donc toi aussi :-p
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 ?
Ca sert à passer du code simplement en paramètre, exemple avec 2 utilisations de callback :
Oui, pleins de projets l'utilise. ca permet par exemple d'écrire quelque chose comme ca :
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 :
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 . É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.