JDK 7: Proposition 9 : Notation de tableau pour List et Map -> Intégrée

Contre dans son etat actuel.

Soit on décide de la surcharge des opérateurs en Java, et ce genre de notation pourra en faire parti, soit on reste purement dans de l'objet avec des notations objets classiques.

Ce dérapage petit a petit ne me plait pas du tout. A mon avis, une situation intermédiaire est dangeureuse.

Donc soit syntaxe completement objet comme en Java, ou alors redefinition de tous les operateurs, comme en Python.

Contre,
pour moi ça porte à confusion avec les tableaux -> relecture difficile

Contre.

Aucun apport, voire une regression pour l'auto-completion des IDE...

Moi je trouve ça excellent et très pratique, je ne vois pas pourquoi certains trouveraient cela illisible

Je pense que de toute façon cette fonctionnalité n'apparaîtra pas car comme il a été dit, l'utilisation des Iterators est préférable, et ajouter cette nouvelle syntaxe encouragera plutôt les développeurs à utiliser les index, ce qui serait un retour en arrière et une source supplémentaire de bugs.

Le foreach était une réelle amélioration.
Les [i] il faut oublier.

Citation:

---

Envoyé par natha

Je pense que de toute façon cette fonctionnalité n'apparaîtra pas car comme il a été dit, l'utilisation des Iterators est préférable, et ajouter cette nouvelle syntaxe encouragera plutôt les développeurs à utiliser les index, ce qui serait un retour en arrière et une source supplémentaire de bugs.

Le foreach était une réelle amélioration.
Les [i] il faut oublier.

---

Sauf qu'en terme de performances merci bien .. teste le nouveau for par rapport a l'ancien utilisant un iterator .. (adiGuba l'a fait les résultat sont édifiant), fait ensuite le même test avec des index .. encore surprenant comme résultat..

Je refuse de perdre en perf pour du sucre syntaxique donc pour moi, exit le nouveau for.. idem avec les iterator, c'est aussi clair qu'un index a la lecture, juste un peu plus secure (pas possible de manipuler l'index) mais tu perds en perf.. moi je reste préhistorique si la voiture a bras dépassé la ferrarri ça me va très bien la voiture a bras..

Bulbo ;)

Note : cette discussion avait dévié vers un débat concernant les performances des for et des itérateurs.

Pour plus de clarté les messages concernés on été déplacés dans une nouvelle discussion : [Perfs] Boucle for et iterateurs

:merci:

Contre,

D'ailleurs, si on part dans cette direction, on va imanquablement ajouter des syntaxe du type :

Code:

---

1 2 3 4 5

void swap(List<String> list) { list[] = "a"; list[] = "b"; }

---

car enfin, l'ascesseur en écriter le plus utilisé n'est pas set (int, Object) mais set(Object). Il lui faudra donc un pendant en terme de crochet. A ce moment là, il pourra être temps de penser a fusionner Java et Php :aie::aie::aie:

Je note au passage que, pour la 4eme proposition Java consécutive, je suis complétement d'accord avec bulbo

Citation:

---

On se dirige un peu trop vers de la surcharge d'opérateurs et je hais ce truc.

---

Une question donc : Bulbo, as-tu un java fan club où je puisse m'inscrire ?

Citation:

---

On se dirige un peu trop vers de la surcharge d'opérateurs et je hais ce truc.

---

Bha moi j'aime bien la surcharge d'opérateur :) Le principe c'est "faire chier le développeur de la classe car il y a une signature particulière mais faciliter d'utilisation pour ceux qui l'utiliseront et liront le code par la suite".

Ca me parait plus "humain" de faire A+B que A.add(B)
Dans le premier cas, à moins d'avoir un développeur pervers dans l'équipe on se doute qu'il y a notion d'addition. Dans le second, cas on sait pas encore si c'est une colletion où on ajoute un élément, si on ajoute A à B (une simple lecture suffira à le déterminer bien sur). Mais je trouve plus humain comme manière de lire par la suite.
Par contre, plus en java qu'en c++, il y aura un gros problème le jour où on voudra surcharger l'opérateur "=" vu que A=B a déjà un sens bien précis en java et le redéfinir va entraîner une vague de crise de nerfs parmi les gens qui vont se palucher du code d'autres personnes (moi le premier)

Pour le lien à la javadoc, si il s'agit d'une surcharge... il suffit de rajouter la fonction "operator[]" à la javadoc à la place de méthode "get"

Par contre, comme pour la comparaison d'énum je ferai la même remarque. On le fait bien de manière globale ou pas du tout. La aussi ça fait vraiment tentative d'insérer le truc.

La preuve pour les énums on l'introduirait d'une manière A et pour ça on l'introduirait de manière B. Pour un prochain exemple on l'implémenterait encore différement.

Ou on réfléchit à une solution globale et pertinente, on ne le fait pas. Stop à la bidouille pour forcer l'ajout d'une seule fonctionnalité.

contre.

Citation:

---

Envoyé par kisame

Bha moi j'aime bien la surcharge d'opérateur :) Le principe c'est "faire chier le développeur de la classe car il y a une signature particulière mais faciliter d'utilisation pour ceux qui l'utiliseront et liront le code par la suite".

---

Je vis la surcharge un peu a l'inverse de toi, le concepteur de la classe "s'amuse" a redéfinir les opérateurs et ceux qui doivent l'utiliser/maintenir après se démerde..

Quand tu redéfinis = pour faire des trucs ésotériques au lieu d'une simple affectation c'est super sympa pour la personne ayant a debugguer/maintenir ce code, c'est très facile de rater le = (et le fait qu'il soit redéfini dans le code).. on voit = on pense affectation et en fait il y a un clonage ou je ne sais quoi de codé derrière et on a une grosse surprise.

Si je n'aime pas la surcharge c'est pour en avoir mangé et le problème n'est pas de l'écrire, au contraire sur le moment c'est super élégant, concis bref un bonheur .. c'est ensuite que ça se corse..

Bulbo ;)

Pour en avoir bouffé également j'en ai gardé un bon souvenir. Mais voilà dans un cas comme dans l'autre. C'est l'expérience qu'on en a eu qui fait notre choix. Moi j'ai eu la chance de travailler sur un projet c++ où les choses étaient parfaitement claires et présentées (commentaires intelligents rédigés)

Par contre

Citation:

---

Quand tu redéfinis = pour faire des trucs ésotériques au lieu d'une simple affectation c'est super sympa pour la personne ayant a debugguer/maintenir ce code, c'est très facile de rater le = (et le fait qu'il soit redéfini dans le code).. on voit = on pense affectation et en fait il y a un clonage ou je ne sais quoi de codé derrière et on a une grosse surprise.

---

(en c++) c'est vrai que c'est toujours sur cet opérateur que tu trouves les trucs les plus bizarres et souvent dans un même projet avec des sens différents (tantôt clonage, tantôt autre chose, ). Le tout c'est de se mettre d'accord pour faire toujours la même chose ou de bien documenter (après faut lire la doc qui va avec l'api que t'as crée, mais moi ça me semble normal)

En java aussi tu peux faire nimp dans un compareTo() (opérateurs <, >, =) ou plus fréquement Clone() (ça peut etre l'opérateur=). J'ai vu des trucs ignobles de fait dans des clone(). Ce n'est pas parce que c'est en java que c'est forcément bien fait.

J'ai pas l'impression que ce que tu condamnes soit le principe de la surcharge mais plutot les gros trucs pourris que t'as vu dans un langage en particulier lors de surcharge d'opérateurs (je sais pas pourquoi mais j'intuite sur le fait que ce soit en C++). Tu peux aussi faire du très bon code en C++ avec de la surcharge :mrgreen:

Citation:

---

Si je n'aime pas la surcharge c'est pour en avoir mangé et le problème n'est pas de l'écrire, au contraire sur le moment c'est super élégant, concis bref un bonheur .. c'est ensuite que ça se corse..

---

bof

écrire en java

Code:

---

1 2 3 4

public int compareTo(A a) { ... blabla }

---

je trouve plus simple que

Code:

---

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

boolean operator< (const A& a) { ... blabla }   boolean operator> (const A& a) { ... blabla }   boolean operator== (const A& a) { ... blabla }

---

Par contre je trouve plus chiant et beaucoup moins naturel à utiliser

Code:

---

1 2 3 4 5 6 7 8

if(a.compareTo(b) == 0) blablalbla ... else if (a.compareTo(b)>0) blablalbla ... else blablalbla ...

---

que

Code:

---

1 2 3 4 5 6 7

if(a==b) blablalbla ... else if (a>b) blablalbla ... else blablalbla ...

---

du coup on pourrait faire des trucs du genre ou pas ?

Code:

---

1 2 3 4 5 6 7 8

List<Integer> liste=.... int a=.. int b=.. liste[a] += b; liste[a]++;   liste[a]=liste[b]++;

---

Oui.

Pour à 100%!

Je ne pense pas que cette fonctionnalités réduirait un temps soit peu la lisibilité du code. Au contraire, ce serait un enrichissement majeur: une syntaxe épurée pour un langage moderne. N'oublions pas que par essence, les opérateurs sont polymorphes. Par exemple, quand je parcoure mon code et que je rencontre une expression comme ceci: z = x + y, je ne pose pas la question de savoir si x, y et z sont des entiers, des flottants ou des chaînes de caractères. Le cas échéant, je n'ai qu'a laisser traîner le curseur de la souris au dessus de chaque identificateur quelques instants pour que l'IDE me renseigne sur son type. De toutes façons, ce n'est pas l'opérateur + qui me renseigne sur le type des objets auxquels il s'applique. Il en va de même pour l'opérateur []. Il pourrait être appliqué à n'importe quel type pour peu que cela ait un sens. Et avec les collections, cela a justement un sens (qui varie selon le type de collection).

Pour à 100%. Ayant 8 ans de Java derrière moi, et étant maintenant du côté sombre (.Net), les itérateurs (entiers, chaîne ou n'importe quel type d'ailleurs) sont géniaux à l'utilisation. Il n'y a absolument pas photo. :king:

C'est pas très POO tout ça.
On aura toujours besoin de méthodes plus complexes que les accesseurs de toute façon. Si c'était simple, on ferait pas bosser des développeurs expérimentés mais des chimpanzés.

Je vote contre,

Tout simplement car je perd l'impression de manipuler un objet et de me retrouver avec des tableaux a taille fixes comme ceux que j'ai utilisé quand j'ai appris en Pascal.

Je verrai plus de grande diférence la dedans :

Code:

---

1 2 3 4 5 6

List<Integer> list = new ArrayList<Integer>(); int[] tableau = new int[NB_MAX]; ... list[1] = 4; tableau[1] = 4;

---

Je vois pas de différenciation lors de leurs utilisations et ca m'embete :?

Je suis vraiment déçu du résultat de ce vote, étant moi-même développeur dans les 2 langages, ce serait vraiment une avancée, simple d'utilisation, efficace et très utile au jour le jour.

Je ne m'en passe plus en C# et je continuerais à me demander pourquoi on ne l'a pas en Java.

La communauté Java me semble bien trop fermée aux évolutions qui ont pourtant fait leur preuve ailleurs, c'est réellement dommage. :?

Cette proposition a finalement été retenu pour l'intégration dans Java 7 : Projet Coin : Les modifications du langage pour Java 7

a++