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.
Et si c'est un autre dev, pas forcement rompu a cette partie du code, qui tente de corriger une anomalie ou qui recupere la maintenance d'un projet?
La surcharge et ce genre de conneries, ca marche tres bien si t'es tout seul dans ton coin sur ton petit projet, mais c'est clairement pas la cible de java.
Sans compter qu'il me semble que le symbole pour les produit vectoriel, un X rigolo, pas une etoile?
Reste toujours que le * ne donne aucune information sur ce qu'a voulu faire le mec qui a ecrit le code.
Ton * est totalement indefinit pour les objets, ca dit juste que c'est une multiplication, charge a l'implementeur de definir la multiplication.
Appelle ca zorglub, ca fait un bofossou, charge a l'implementeur de definir le bofossou, c'est pas tellement different.
Bon ok, je pousse un peu, ca va souvent etre comprehensible, mais t'es jamais vraiment sur. Et dans certains cas, ca va etre clairement super ambigue. Genre le cas de la list, le + peut etre parfaitement raisonnablement interprete de 2 facons completement opposees.
Quand je lit list.add(list) ou list.addAll(list), je sais tres exactement ce que le mec qui a ecrit le code a voulu faire.
Quand je lit list + list, j'en sais trop rien. Je suis pas dans sa tete, donc je ne sais meme pas si le probleme se trouve dans + ou dans l'expression, parce que je ne sais meme pas ce que le mec a voulu ecrire en premier lieu.
Il aurait pu ecrire list zorglub list je serais pas plus avance.
En general, ca passe, mais quand ca passe pas, on fait quoi? On s'encule? Si c'est un bug cho cho cho en prod, avec des mecs en cravate derriere toi qui te fouttent et te promettent un monde de douleur si c'est pas regle d'ici une heure, tu vas probablement te dire que cet abruti qui a ecrit ce bug, il aurait mieux fait d'ecrire 5 caracteres de plus. Ou de se casser une jambe.
Tout ca pour quoi?
Pour ne pas avoir a ecrire equals?
Perso je prend les 5 characteres en plus, les coups de fouet, c'est quand ca s'arrete que ca fait du bien, et si je peux eviter d'ajouter des petits problemes aux grands, je le fait tres volontiers.
Ben en même temps, un produit vectoriel, ce sont des maths, une comparaison de valeurs, ce sont des maths.
Ouch! Ca fait mal au coeur de lire ca.
Je ne m'aventurerais pas sur la partie produit vectoriel. Un peu quand meme. C'est une operation faite par un objet sur un autre objet. Pas une operation mathematique. En tout cas, pas dans le paradigme objet. Ca va dependre fortement de ton modele.
Tu peux vouloir une exception quand c'est pas defini, passer ca sous silence, bref, c'est tout sauf clairement definit. Et par clairement, j'entends 0 doutes, nada, pas "bah, il doit vouloir dire ca".
La comparaison de valeur, dans une logique objet, c'est tout sauf des maths. L'identite des objets change du tout au tout en fonction du domaine et du modele implemente. Ca n'a rien d'une operation mathematique, les valeurs peuvent etre identiques et pourtant ne pas etre egale.
Mon gateau, c'est mon gateau, ton gateau c'est ton gateau, ils sont differents, et pourtant ya strictement la meme chose dedans (des pepite de chocolat :) ). Pour le fabriquant, il s'en tamponne, c'est tous les memes, fout moi ca dans une boite et envoie tout ca au supermarche.
J'appelle pas ca des maths perso.
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.
Evidemment que + est specifie, sa specification etant indefinie. C'est un gros fourre tout qui sert a mettre un peu tout et n'importe quoi.
Add transporte une semantique bien plus forte. Tu dis ce que tu veux faire en ecrivant ca. Si apres coup on se rend compte que le nom est mal choisi, ben on peut le changer, mais c'est pas trop le sujet ici.
+ c'est grosso modo un alias pour dire "va voir dans la doc, pardon le code, comment + est defini et ce qu'il veut dire". J'ai voulu utiliser un zorglub et si tu veux etre sur a 100% de ce que j'ai voulu faire, ben va falloir venir me demander.
Je trouve A*(B*c) au moins 42 fois plus lisible que la version avec une variable temporaire.
J'avoue que le temp est pas joli joli. C'est un moindre mal on va 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: 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.
Et si c'est un autre dev, pas forcement rompu a cette partie du code, qui tente de corriger une anomalie ou qui recupere la maintenance d'un projet?
La surcharge et ce genre de conneries, ca marche tres bien si t'es tout seul dans ton coin sur ton petit projet, mais c'est clairement pas la cible de java.
Sans compter qu'il me semble que le symbole pour les produit vectoriel, un X rigolo, pas une etoile?
Reste toujours que le * ne donne aucune information sur ce qu'a voulu faire le mec qui a ecrit le code.
Ton * est totalement indefinit pour les objets, ca dit juste que c'est une multiplication, charge a l'implementeur de definir la multiplication.
Appelle ca zorglub, ca fait un bofossou, charge a l'implementeur de definir le bofossou, c'est pas tellement different.
Bon ok, je pousse un peu, ca va souvent etre comprehensible, mais t'es jamais vraiment sur. Et dans certains cas, ca va etre clairement super ambigue. Genre le cas de la list, le + peut etre parfaitement raisonnablement interprete de 2 facons completement opposees.
Quand je lit list.add(list) ou list.addAll(list), je sais tres exactement ce que le mec qui a ecrit le code a voulu faire.
Quand je lit list + list, j'en sais trop rien. Je suis pas dans sa tete, donc je ne sais meme pas si le probleme se trouve dans + ou dans l'expression, parce que je ne sais meme pas ce que le mec a voulu ecrire en premier lieu.
Il aurait pu ecrire list zorglub list je serais pas plus avance.
En general, ca passe, mais quand ca passe pas, on fait quoi? On s'encule? Si c'est un bug cho cho cho en prod, avec des mecs en cravate derriere toi qui te fouttent et te promettent un monde de douleur si c'est pas regle d'ici une heure, tu vas probablement te dire que cet abruti qui a ecrit ce bug, il aurait mieux fait d'ecrire 5 caracteres de plus. Ou de se casser une jambe.
Tout ca pour quoi?
Pour ne pas avoir a ecrire equals?
Perso je prend les 5 characteres en plus, les coups de fouet, c'est quand ca s'arrete que ca fait du bien, et si je peux eviter d'ajouter des petits problemes aux grands, je le fait tres volontiers.
Ben en même temps, un produit vectoriel, ce sont des maths, une comparaison de valeurs, ce sont des maths.
Ouch! Ca fait mal au coeur de lire ca.
Je ne m'aventurerais pas sur la partie produit vectoriel. Un peu quand meme. C'est une operation faite par un objet sur un autre objet. Pas une operation mathematique. En tout cas, pas dans le paradigme objet. Ca va dependre fortement de ton modele.
Tu peux vouloir une exception quand c'est pas defini, passer ca sous silence, bref, c'est tout sauf clairement definit. Et par clairement, j'entends 0 doutes, nada, pas "bah, il doit vouloir dire ca".
La comparaison de valeur, dans une logique objet, c'est tout sauf des maths. L'identite des objets change du tout au tout en fonction du domaine et du modele implemente. Ca n'a rien d'une operation mathematique, les valeurs peuvent etre identiques et pourtant ne pas etre egale.
Mon gateau, c'est mon gateau, ton gateau c'est ton gateau, ils sont differents, et pourtant ya strictement la meme chose dedans (des pepite de chocolat :) ). Pour le fabriquant, il s'en tamponne, c'est tous les memes, fout moi ca dans une boite et envoie tout ca au supermarche.
J'appelle pas ca des maths perso.
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.
Evidemment que + est specifie, sa specification etant indefinie. C'est un gros fourre tout qui sert a mettre un peu tout et n'importe quoi.
Add transporte une semantique bien plus forte. Tu dis ce que tu veux faire en ecrivant ca. Si apres coup on se rend compte que le nom est mal choisi, ben on peut le changer, mais c'est pas trop le sujet ici.
+ c'est grosso modo un alias pour dire "va voir dans la doc, pardon le code, comment + est defini et ce qu'il veut dire". J'ai voulu utiliser un zorglub et si tu veux etre sur a 100% de ce que j'ai voulu faire, ben va falloir venir me demander.
Je trouve A*(B*c) au moins 42 fois plus lisible que la version avec une variable temporaire.
J'avoue que le temp est pas joli joli. C'est un moindre mal on va 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.