Juste pour être sur qu'on est sur la meme page, ce que tu propose, c'est d'avoir == pour l'égalité de valeur tout le temps, et equals pour celle de pointeur?
Ou juste surcharger == pour faire de l'égalité de valeur ponctuellement, avec un plan b pour l'égalité de pointeurs?
Le problème fondamental avec la surcharge de == (ou meme l'échange de == et de equals), c'est que ça transforme une opération très simple de comparaison d'entiers en appel de methode sur des objets, avec tous les problèmes que ça amène. Et en plus, c'est impossible de savoir simplement en lisant le code si ça va aller a une méthode ou pas.
En gros:
1) c'est plus nulle safe et ça pete la symetrie de ==.
Object a = null;
Object b = new Object()
a == b; // NPE
b == a; // false.
2) Ca rend le code beaucoup plus difficile a relire, vu qu'il est désormais impossible de savoir ce que == est censé faire. Ca c'est un énorme problème a mes yeux. Du code, ça doit se lire comme un livre. Si lire du code se lit dans un langage naturel, très expressif (modulo les quelques trucs technique, évidemment), la maintenabilite a fait un énorme bond en avant. N'importe qui peut lire le code, se rendre compte d'un problème. Ou s'occuper d'un bug et comprendre 'achement plus vite ce qu'il se passe.
Et c'est encore plus important en java qui est majoritairement utilise dans un contexte entreprise, ce qui veut dire appli critiques maintenues pendant des années, voire des dizaines d'années, et très souvent ecrites/maintenues par une bande de bras casses. La simplicité et la clarté sont vitales dans ce contexte. Non pas qu'ils soient pas importants dans d'autre contexte, mais en java c'est vraiment important.
3) Potentiellement, tes objets vont lazy loader dans une base de données sur equals. Ton code qui parait tout innocent va maintenant aller tirer un gros paquet de données de façon pas visible du tout.
4) il est maintenant interdit d'utiliser == dans un bout de code un tant soit peu générique, vu que tu peux pas savoir ce que ça va faire.
5) Conceptuellement, si tu veux appeler une méthode sur un objet, ben appelle une méthode dessus :) Plutot que de mapper un opérateur a une méthode implicitement.
Bon, ça c'est pour les problèmes que ça ammene.
Niveau avantage, on gagne quoi au juste? J'ai du mal a comprendre en fait.
Ce qui dérange c'est de taper .equals a la place de == ?
Ben ouais, mais bon. Vous etes vraiment si fainéant que ça? C'est quoi la prochaine étape, remplacer new par n parce que c'est trop long a taper?
D'une part, c'est pas la fin du monde, c'est pas comme si .equals était dur a taper. Et c'est pas comme si on avait des environnements de dev qui s'occupe de taper la moitié du code a la place du dev.
Donc, on perd énormément en clarté, tout ça pour économiser quelques caractères a droite a gauche?
Plus sérieusement, dans une application écrite en java, quels sont les applications pratiques de l'égalité de pointeur ?
Savoir si les instances sont les memes.
Ca a son utilité, tu peux vouloir vérifier que deux objets pointent au meme endroit, sans se soucier de savoir s'ils ont la meme valeur ou pas.
Généralement la partie «métier» va jouer sur les valeurs, et tout ce qui est plus bas niveau pourrait jouer sur des pointeurs, non ?
Ou pas, tu peux pas tirer de generalites sur un truc aussi large qu'un langage. Et si ton domaine c'est le bas niveau, ta logique métier va jouer sur les valeurs ET les pointeurs.
qui en plus aurait l'avantage d'être cohérent avec l'égalité de valeur des types de base...
Comment ça? == est cohérent, il compare le contenu des variables.
Il ne s'occupe pas du sens que tu donnes a ces variables.
Java a clairement des problèmes, mais pas a ce niveau.
Parlez moi de leur implémentation foireuse des generics, de l'absence de closure (encore que ça m'a jamais vraiment manque ça), de l'API Date qui est une énorme blague, de l'absence de properties, de l'absence de collections immuables, de l'absence de string/nombre mutables, de leur fast iterator des bois qui te pete des NPE sur une collection nulle et des autres trucs que j'oublie.
Et comme dit ailleurs, faut pas oublier que le langage a maintenant 20 ans. Un des objectifs c'était "du code écrit aujourd'hui tournera encore dans 20 ans", cet objectif est clairement atteint.
Dans un domaine aussi dynamique que le développement soft, je trouve que sun s'en est plutôt bien sorti dans l'ensemble.
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: Les vrais ajouts
Posté par pasScott pasForstall . En réponse au journal Java 7 est dispo !. Évalué à -4.
Juste pour être sur qu'on est sur la meme page, ce que tu propose, c'est d'avoir == pour l'égalité de valeur tout le temps, et equals pour celle de pointeur?
Ou juste surcharger == pour faire de l'égalité de valeur ponctuellement, avec un plan b pour l'égalité de pointeurs?
Le problème fondamental avec la surcharge de == (ou meme l'échange de == et de equals), c'est que ça transforme une opération très simple de comparaison d'entiers en appel de methode sur des objets, avec tous les problèmes que ça amène. Et en plus, c'est impossible de savoir simplement en lisant le code si ça va aller a une méthode ou pas.
En gros:
1) c'est plus nulle safe et ça pete la symetrie de ==.
Object a = null;
Object b = new Object()
a == b; // NPE
b == a; // false.
2) Ca rend le code beaucoup plus difficile a relire, vu qu'il est désormais impossible de savoir ce que == est censé faire. Ca c'est un énorme problème a mes yeux. Du code, ça doit se lire comme un livre. Si lire du code se lit dans un langage naturel, très expressif (modulo les quelques trucs technique, évidemment), la maintenabilite a fait un énorme bond en avant. N'importe qui peut lire le code, se rendre compte d'un problème. Ou s'occuper d'un bug et comprendre 'achement plus vite ce qu'il se passe.
Et c'est encore plus important en java qui est majoritairement utilise dans un contexte entreprise, ce qui veut dire appli critiques maintenues pendant des années, voire des dizaines d'années, et très souvent ecrites/maintenues par une bande de bras casses. La simplicité et la clarté sont vitales dans ce contexte. Non pas qu'ils soient pas importants dans d'autre contexte, mais en java c'est vraiment important.
3) Potentiellement, tes objets vont lazy loader dans une base de données sur equals. Ton code qui parait tout innocent va maintenant aller tirer un gros paquet de données de façon pas visible du tout.
4) il est maintenant interdit d'utiliser == dans un bout de code un tant soit peu générique, vu que tu peux pas savoir ce que ça va faire.
5) Conceptuellement, si tu veux appeler une méthode sur un objet, ben appelle une méthode dessus :) Plutot que de mapper un opérateur a une méthode implicitement.
Bon, ça c'est pour les problèmes que ça ammene.
Niveau avantage, on gagne quoi au juste? J'ai du mal a comprendre en fait.
Ce qui dérange c'est de taper .equals a la place de == ?
Ben ouais, mais bon. Vous etes vraiment si fainéant que ça? C'est quoi la prochaine étape, remplacer new par n parce que c'est trop long a taper?
D'une part, c'est pas la fin du monde, c'est pas comme si .equals était dur a taper. Et c'est pas comme si on avait des environnements de dev qui s'occupe de taper la moitié du code a la place du dev.
Donc, on perd énormément en clarté, tout ça pour économiser quelques caractères a droite a gauche?
Savoir si les instances sont les memes.
Ca a son utilité, tu peux vouloir vérifier que deux objets pointent au meme endroit, sans se soucier de savoir s'ils ont la meme valeur ou pas.
Ou pas, tu peux pas tirer de generalites sur un truc aussi large qu'un langage. Et si ton domaine c'est le bas niveau, ta logique métier va jouer sur les valeurs ET les pointeurs.
Comment ça? == est cohérent, il compare le contenu des variables.
Il ne s'occupe pas du sens que tu donnes a ces variables.
Java a clairement des problèmes, mais pas a ce niveau.
Parlez moi de leur implémentation foireuse des generics, de l'absence de closure (encore que ça m'a jamais vraiment manque ça), de l'API Date qui est une énorme blague, de l'absence de properties, de l'absence de collections immuables, de l'absence de string/nombre mutables, de leur fast iterator des bois qui te pete des NPE sur une collection nulle et des autres trucs que j'oublie.
Et comme dit ailleurs, faut pas oublier que le langage a maintenant 20 ans. Un des objectifs c'était "du code écrit aujourd'hui tournera encore dans 20 ans", cet objectif est clairement atteint.
Dans un domaine aussi dynamique que le développement soft, je trouve que sun s'en est plutôt bien sorti dans l'ensemble.
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.