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.
Non, c'est sur.
Apres, la difference se fait sur la relecture du code.
Le code est lu par des humains, et les humains ont un fonctionnement un peu particulier.
Quelqu'un qui lit + va automatiquement comprendre ca comme l'operateur mathematique, a savoir 1 + 1.
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.
Appelle ca vecteur1.produitVectoriel(vecteur2), ca devient tout de suite beaucoup plus clair pour tout le monde.
Et on sait exactement ce qu'il se passe si le premier membre est null (pas dans l'autre cas).
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".
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.
Le probleme est que tu assumes que + se mappe forcement semantiquement a add.
Prend une liste par exemple, elle definit add.
mais liste1 + liste2 est semantiquement TRES different de list1.add(list2). Ce que tu veux dans ce cas, c'est un addAll.
C'est juste une mauvaise idee.
L'autoboxing marche pour Number parce que d'une part sun^W oracle controle le langage et le framework, d'autre part, ya effectivement une correspondance one to one entre Integer et int, et donc une correspondance one to one entre + pour Integer et l'operateur + mathematique. Dans ce cas ca marches tres bien.
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.
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)
C'est ce que fait java avec l'autoboxing, et le resultat est pas joli joli. Ca marche dans les cas simples, le reste du temps, c'est chiant a utiliser: on pense avoir un truc simple, mais en fait il est complique.
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.
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: Utiliser les tty
Posté par pasScott pasForstall . En réponse à la dépêche Patch pour le noyau Linux améliorant l'interactivité entre les applications console et Xorg. Évalué à 1.
Non, c'est sur.
Apres, la difference se fait sur la relecture du code.
Le code est lu par des humains, et les humains ont un fonctionnement un peu particulier.
Quelqu'un qui lit + va automatiquement comprendre ca comme l'operateur mathematique, a savoir 1 + 1.
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.
Appelle ca vecteur1.produitVectoriel(vecteur2), ca devient tout de suite beaucoup plus clair pour tout le monde.
Et on sait exactement ce qu'il se passe si le premier membre est null (pas dans l'autre cas).
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".
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.
Le probleme est que tu assumes que + se mappe forcement semantiquement a add.
Prend une liste par exemple, elle definit add.
mais liste1 + liste2 est semantiquement TRES different de list1.add(list2). Ce que tu veux dans ce cas, c'est un addAll.
C'est juste une mauvaise idee.
L'autoboxing marche pour Number parce que d'une part sun^W oracle controle le langage et le framework, d'autre part, ya effectivement une correspondance one to one entre Integer et int, et donc une correspondance one to one entre + pour Integer et l'operateur + mathematique. Dans ce cas ca marches tres bien.
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.
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)
C'est ce que fait java avec l'autoboxing, et le resultat est pas joli joli. Ca marche dans les cas simples, le reste du temps, c'est chiant a utiliser: on pense avoir un truc simple, mais en fait il est complique.
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.
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.