2PetitsVerres a écrit 3119 commentaires

Et il n'a pas dit que c'était gratuit. Les niches fiscales du genre "investissement immobilier", c'est pas gratuit non plus, le mariage c'est pas gratuit, …

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Transports publics, en particulier quand on écrit PUBLIQUE en lettres capitales ;-)

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Je pense que le blocage du système d'éducation PUBLIC t'a grandement handicapé.

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

En même temps, tu veux pas être embarqué dans sa solution, mais peut-être que lui ne voulait pas être embarquée dans celle choisie, et il n'a pourtant pas eu le choix.

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Ce genre d'operateur est commutatif (je pense que c'est ce que tu voulais dire ;-) ) juste parce qu'il est commutatif dans ton langage. Il y a d'autre opérateurs qui ne le sont pas. Si tu préviens le développeur quand tu lui apprends le langage, ça ne pose pas de problèmes (sauf si c'est un lapin nain de deux jours)

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Pour ==, non, je ne veux pas de confusion entre les deux. J'ai précisé tout à l'heure que je ne veux pas un == (ou autre opérateur) qui soit par défaut de pointeur et que je peux surcharger. Je veux un opérateur qui soit par défaut de valeur et que je peux surcharger. Et hop, pas de choses opposée.

Pour trouver equals, tu fais comment ? Tu cherches dans les 2500 résultat de ta recherche de equals ? Non parce que si ton ide est capable de te trouver tout tes type1.equals(typeX), il est aussi capable de te trouver tout tes (type1 == typeX)

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Meme si l'humain est capable de comprendre que vecteur1 x vecteur2 est le produit vectoriel de 2 vecteur, ca fait une gymnastique mentale supplementaire et parfaitement comprendre le context, ce qui n'est pas desirable pour un relecteur externe.
Sauf si le relecteur externe c'est le gars qui a mis au point les lois de contrôle et que lui, justement, il sait mieux lire a x b que a.produitVectoriel(b). Mais bon, le mieux pour coder les parties mathématiques d'un algo, c'est quelqu'un qui est capable de comprendre ce que le concepteur dit, dans sa langue, qui est les maths.


Le dev peut affreusement nommer ses methodes (et il le fait souvent), certes, mais le langage n'y peut rien. La ou le langage peut, c'est limite la casse et t'empecher d'introduire une ambiguite dans ton code en disant "les operateurs, c'est pour les maths, point".

Ben en même temps, un produit vectoriel, ce sont des maths, une comparaison de valeurs, ce sont des maths.


Pour tous les autres objets, la correspondance n'est clairement pas la, sa presence va dependre de tellement de parametre qu'utiliser + revient sensiblement a la meme chose que d'appeler une methode zorglub: ca t'avances pas des masses sur ce que fait la methode.


Ta méthode + sur ton objet, elle a une spécification. Elle parle aussi de l'addition. Le dev qui est capable de faire une méthode add, equals cohérente, il est capable de faire une surcharge cohérente. Le type qui appelle sa méthode zorglub, il fera pas mieux avec la surcharge, c'est sûr.


Ton exemple avec les matrices est parfait.
Ta surcharge d'operateur * sur les matrices casse la lecture naturelle du code et rends ton code plus fragile. La validite du code tient a une paire de parentheses.
Force a ecrire temp = b.multiply(v); v = a.multiply(temp), ton code y gagne en clarete (plus besoin d'evaluer la priorite des operateurs patati patata) et c'est beaucoup plus explicite.
Tu sais que t'appelles telle implementation de la multiplication et dans quel ordre.

Ouais ben c'est là qu'on est pas d'accord et qu'on arrivera pas à se mettre d'accord (c'est pas grave en même temps). Je trouve A*(B*c) au moins 42 fois plus lisible que la version avec une variable temporaire. Pour savoir quelle implémentation tu appelles, ben c'est facile. Si t'as plusieurs implémentations de la même multiplication matrice vecteur dans ton projet, soit tu as du code inutile, soit tu as un cas général (=a utiliser dans la surcharge) et un cas particulier à utiliser dans certaines circonstances, et c'est précisé dans ta spécification.

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Génial, donc ta solution miracle vu que c'est dangereux un "==" dont tu ne sais pas ce qu'il fait, c'est d'utiliser une méthode equals() dont tu ne sais pas ce qu'elle fait. Ah pardon, comme c'est 6 caractères et pas deux, tu sais exactement ce qu'elle fait !
En plus, ton opérateur surchargé == pourrait ne plus marcher parce que tu l'auras supprimé, alors que quand tu supprimes ton equals() tout continue sans que ça pète silencieusement.

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

En quoi c'est plus dur à lire ? Moi je trouve qu'écrire (a = b) en Ada, c'est plus lisible que (a.equals(b)) en java.

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Sauf s'il marche comme l'operateur == actuel. J'en veux pas à cet opérateur, c'est juste que je voudrais un opérateur d'égalité de valeur.

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

ben je ferais un (a.maSuperMethodeQuiCompareLesPointeursEtQuiPourraitEtrePlusCourte(null)) (ça pourrait être un opérateur aussi hein, genre (a =*= null)

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Et comment tu fais quand tu veux une comparaison de pointeurs? On rajoute un deuxieme operateur?
Dans ce cas, je cite mon commentaire
je ne suis pas contre une méthode ou un opérateur permettant de récupérer la même chose que le (a == b) actuel

Et pour ton exemple plus bas, justement, j'aurais préféré que ce soit partout un == de valeur, pas de pointeur. Donc évidemment java ne peut pas évoluer dans ce sens (trop d'héritage existant, étant donné que c'est ce qui existe depuis le début)

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Je ne suis pas d'accord avec toi. Effectivement, si un type surcharge "+" par une multiplication, c'est pas maintenable. Mais en même temps, si un dev java invente une méthode add() qui multiplie, ça sera pas plus maintenable que dans n'importe quel autre langage. Quand à dire que la surcharge c'est pas joli en objet, je dirais que dès le moment où tu peux faire a+b quand ce sont des int, je ne vois pas ce qui gênerait à l'autoriser pour d'autres objets. Quitte à restreindre l'utilisation à un sous-ensemble d'objets bien identifiés (genre Object->Mathematic ou un truc du genre) avec un ensemble de méthodes identifiées (Type1+ Type2 serait automatiquement un appel Type1.add(Type2) s'il existe, une erreur si ça n'existe pas)

Je sais que ce n'est pas très gênant dans certaines applications, mais quand tu as des calculs à faire, par endroit, ça serait bien (je fais parfois de l'Ada au boulot, on a une bibliothèque mathématique validée, qui n'utilise pas la surcharge qui est possible en Ada. Rien de plus pénible que de voir qu'un calcul matriciel v' = A*B*v par exemple prendre 3 lignes de pleins de caractères. Bon évidement, quand on écrit
tmp_v = mult_m_v(matrice => B; vect => v);
v' = mult_m_v(matrice => A; vect => tmp_v);
on maîtrise ce qui est fait en premier. Mais on est quand même capable d'écrire (quitte à mettre dans les règles de codage qu'on doit absolument associer par parenthèse ce que l'on veut))
v' = A*(B*v);

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Mon avis c'est que ça aurait été beaucoup plus sympa (pour le programmeur) que (a == b) renvoie la même chose que a.equals(b). Je comprends bien le mécanisme dans java (et il n'est pas compliqué), et je ne suis pas contre une méthode ou un opérateur permettant de récupérer la même chose que le (a == b) actuel, mais en temps qu'utilisateur (en temps que développeur) occasionnel de Java, je préférerais l'autre possibilité. Enfin, je ne connais pas (encore ?) de langage où aucun détail ne me plaît pas.
Bon, évidemment, faire un truc tel que (a == b) serait équivalent à (a.equals(b)) poserait aussi le problème pour un "débutant" qu'on aurait pas forcément (a == b) équivalent à (b == a)

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Je ne comprends pas pourquoi je suis moinssé. Quelqu'un peut-il me montrer précisément où je me trompe ?

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

* * Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.

C'est dans la BSD. C'est une licence courte, et pourtant plein de monde ne la comprend pas.

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Mondial, c'est vite dit. Latitude > 0, longitude étalée sur moins de 180°, moins d'un quart de sphère.

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Keynote ne marche que sous mac os x. Comme ça ne tourne pas sous lin^WWindows, aucune chance de détrôner l'autre truc atroce.

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Pour la killer feature en HTML5, si on la fait dans des servlets reposants sur des EJB le tout dans un serveur d'application J2EE, on perd aussi des points ?

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Au moins quelque centaines de millions d'années avant l'apparition de la vie, une paire de siècle de pax romana, par exemple.

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

La poudre à canon a tenu bien plus de 65 ans avant de devenir négative.

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

"Ce n'était jamais arrivé auparavant" n'importe quoi.

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

L'utilisation que les états-unis en ont eu, j'appellerais pas ça de la dissuasion. Bon, c'était pendant la guerre, c'est vrai. Mais bon, un jour ou l'autre, peut-être que ce sera à nouveau la guerre pour un de ces pays…

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Si j'avais dit la Suède tu aurais dit qu'ils ont déjà eu l'arme nucléaire.

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Ils ont pourtant probablement raison, ils sont juste en avance. Il est probable qu'un jour on soit à moins de 10 ans de recherche d'une fusion utilisable. Sauf si on utilise la fusion à grande échelle avant.

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.