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.
[^] # Re: Utiliser les tty
Posté par 2PetitsVerres (Mastodon) . En réponse à la dépêche Patch pour le noyau Linux améliorant l'interactivité entre les applications console et Xorg. Évalué à 3.
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.