Discussion :

[Iradrille]

Hello,

Venant du c++, le java me pose pas mal de problèmes, j'ai (enfin) compris pourquoi une fonction "swap" n'était pas possible en java, grâce à cet article, mais du coup je me pose une question, pourquoi est-ce que ces 2 lignes sont valides ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public void tricky(Point arg1, Point arg2)
{
  arg1.x = 100;
  arg1.y = 100;
  Point temp = arg1;
  arg1 = arg2; // celle la
  arg2 = temp; // et celle la
}
public static void main(String [] args)
{
  Point pnt1 = new Point(0,0);
  Point pnt2 = new Point(0,0);
  System.out.println("X: " + pnt1.x + " Y: " +pnt1.y); 
  System.out.println("X: " + pnt2.x + " Y: " +pnt2.y);
  System.out.println(" ");
  tricky(pnt1,pnt2);
  System.out.println("X: " + pnt1.x + " Y:" + pnt1.y); 
  System.out.println("X: " + pnt2.x + " Y: " +pnt2.y);  
}

Modifier une copie d'une référence n'a que peut d'intérêt et est trompeur (quand on à pas l'habitude du moins).
Bref je comprend pas trop pourquoi ces références sont assignables.

[thelvin]

Il me semble bien plus pragmatique d'autoriser :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
public int handleSkin(String skin) {
  // mise en conformité
  if(skin == null) {
    skin = DEFAULT_SKIN;
  }
 
  // vrai traitement
  return skin.length();
}

que de forcer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
public int handleSkin(String skinAsAnUnrefinedParameter) {
  // mise en conformité
  String skin;
  if(skinAsAnUnrefinedParameter == null) {
    skin = DEFAULT_SKIN;
  } else {
    skin = skinAsAnUnrefinedParameter;
  }
 
  // vrai traitement
  return skin.length();
}

Au passage, ces mêmes assignations sont aussi autorisées en C++ même si les paramètres ne sont pas des &-références. Auquel cas, les règles sont exactement les mêmes qu'en Java, avec exactement le même intérêt.

[tchize_]

et si tu veux éviter de te confuser tu fais ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

public void tricky(final Point arg1, final Point arg2)

[chortani]

Bonsoir,

c'est valide parce que vous pouvez assigner une référence à une autre de même type (même class ou class parent). Si vous voulez interdire ça dans les methode vous pouvez utilisez le mot clé final

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
public void tricky(final Point arg1, final Point arg2)
{
  arg1.x = 100;
  arg1.y = 100;
  Point temp = arg1;
  arg1 = arg2; // probleme compilation
  arg2 = temp; //  probleme compilation
}

vous aurez :

Compilation Errors Detected

Line: 14
final parameter arg1 may not be assigned

Line: 15
final parameter arg2 may not be assigned

[Iradrille]

Au passage, ces mêmes assignations sont aussi autorisées en C++ même si les paramètres ne sont pas des &-références. Auquel cas, les règles sont exactement les mêmes qu'en Java, avec exactement le même intérêt.

J'y avais pas pensé, mais effectivement c'est la même chose que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
void tricky(Point *arg1, Point *arg2) {
	// ...
}

Pour final, c'est du coup équivalent à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
void tricky(Point *const arg1, Point *const arg2) {
	// ...
}

Y a t'il un équivalent à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
void tricky(const Point *arg1, const Point *arg2) {
	arg1->x = 42; // 'x' cannot be modified because it is being accessed through a const object
	arg1 = arg2; // ok, arg1 et arg2 pointent sur le même objet
}

(c'est affreux de bloquer sur des problèmes de ce genre, un jour je comprendrais la logique de ce langage, un jour...)

edit: pas de const-correctness en Java, faut donc utiliser des wrappers sur des objets pour interdire les modifications. (http://stackoverflow.com/questions/1...-specific-to-c)

[thelvin]

Pas besoin de chercher la logique très loin, si tu veux mon avis. Il a pas semblé utile d'en prévoir une, c'est tout.
Personnellement je trouve qu'on a finalement un peu trop souvent des bugs parce que le programmeur "ne sait plus" s'il devrait pouvoir muter l'objet ou non, et qu'il le fait, provoquant une erreur incompréhensible due à un objet muté à un moment où il était totalement débile de le muter. Je suis donc pas vraiment d'accord avec le choix qui a été fait pour Java, mais bon, c'est comme ça.

En C++ la const-correctness repose sur des annotations indiquant pour chaque méthode si oui ou non elle peut muter l'objet, et donc si oui ou non elle a le droit d'être appelée sur un objet à const-correctness. Et bien sûr il ne faut pas se tromper.
J'imagine qu'à l'époque ça a dû sembler une contrainte exagérée, même si depuis Java 6 la mode de mettre des annotations pour tout est finalement revenue.

[adiGuba]

Salut,

Y a t'il un équivalent à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
void tricky(const Point *arg1, const Point *arg2) {
	arg1->x = 42; // 'x' cannot be modified because it is being accessed through a const object
	arg1 = arg2; // ok, arg1 et arg2 pointent sur le même objet
}

(c'est affreux de bloquer sur des problèmes de ce genre, un jour je comprendrais la logique de ce langage, un jour...)

Il n'y a pas vraiment d'équivalent syntaxique...



Mais perso je te conseillerai d'éviter de chercher des équivalences entre le C++ et Java.
Même s'il s'agit de deux langages orienté objets avec une syntaxe relativement proche, ils ont chacun une approche très différentes !

Un bon code C++ ne sera pas forcément adapté à Java, et inversement.


a++

[JoeChip]

un jour je comprendrais la logique de ce langage

Je ne comprend pas ce que tu veux dire par là... Inutile de savoir pourquoi un langage est fait comme ceci ou comme cela : ce qui compte c'est de savoir comment faire ceci ou cela. Comprendre un langage, c'est savoir lire sa doc.

[adiGuba]

@JoeChip : en comparaison de C++, Java a quand même une approche très différente de la POO, avec des notions très différentes.
Il y a vraiment de quoi être troubler lorsqu'on passe de l'un à l'autre (et dans les deux sens).


a++

[JoeChip]

Certes. Mais en l'occurence ça ne semble pas conceptuellement très différent...

[Iradrille]

Je ne comprend pas ce que tu veux dire par là... Inutile de savoir pourquoi un langage est fait comme ceci ou comme cela : ce qui compte c'est de savoir comment faire ceci ou cela. Comprendre un langage, c'est savoir lire sa doc.

Je rejoins adiGuda là dessus, connaître un langage n'est pas simplement connaître sa syntaxe, c'est surtout savoir l'utiliser de manière idiomatique.

@adiGuba, je suis bien conscient que "traduire" un code C++ <-> Java (quelque soit le sens de la "traduction"), c'est mal et que ça mènera soit à un code dégueulasse (avec de la chance), soit à un truc qui marche pas.

Mais savoir l'équivalent de petits morceaux de codes (ici des prototypes de fonctions) aide pas mal : quand je vois un prototype de fonction en C++ je sais exactement ce que ça veut dire, mais j'ai encore du mal à bien comprendre en Java.
Mais ça s'éclairci peu à peu.

Certes. Mais en l'occurence ça ne semble pas conceptuellement très différent...

Et pourtant, en C++, les paramètres sont passés par référence ou référence constante dans une majorité de cas. Les références en Java sont conceptuellement très différentes des références en C++, et s'apparentent plus à des pointeurs, qui eux ne sont que rarement utilisés (on y préfère les smart pointers).

[thelvin]

Les références en Java sont conceptuellement très différentes des références en C++, et s'apparentent plus à des pointeurs, qui eux ne sont que rarement utilisés (on y préfère les smart pointers).

Euh, sauf que... Les références en Java s'apparentent plus à des smart pointers, si tu vas par là -_-°.

[JoeChip]

Ce que je veux dire, c'esr qu'à la question "pourquoi les paramètres sont-ils assignables ?" la réponse devrait être "parce que c'est ce que tu as choisi en écrivant comme ça". Tous les langages sont différents mais c'est dans la doc, quoi. Il n'y a pas de "pourquoi ?", opérationnellement parlant, mais un "comment ?". Si je veux utiliser un langage que je ne connais pas, je cherche à savoir comment faire ce que j'ai à faire, et non pourquoi. Quand je me demande "pourquoi ce langage m'oblige à faire ça ainsi ?" ça veut surtout dire que je trouve "ça" mal fait dans ce langage, et c'est plutôt par énervement contre ses concepteurs que pour travailler plus vite.

[thelvin]

Quand je me demande "pourquoi ce langage m'oblige à faire ça ainsi ?" ça veut surtout dire que je trouve "ça" mal fait dans ce langage, et c'est plutôt par énervement contre ses concepteurs que pour travailler plus vite.

Pas moi. J'en cherche les véritables raisons historiques et techniques, afin d'utiliser les outils existants de la manière dont ils ont été pensés.
Parfois c'est juste que ça a pas été pensé, parfois elles tapent à côté ou sont mauvaises, parfois elles étaient parfaitement logiques dans leur contexte mais plus d'actualité... Ça arrive. C'est même assez commun.

Mais je cherche à savoir et comment m'y adapter une fois que j'ai la connaissance.

[Iradrille]

Euh, sauf que... Les références en Java s'apparentent plus à des smart pointers, si tu vas par là -_-°.

Tu marques un point.

@JoeChip, on peut simplement accepter les choses telles qu'elles sont et juste chercher comment arriver au résultat voulu, mais on peut aussi se demander pourquoi telle ou telle opération est possible (ou impossible) sur un objet (sans pour autant critiquer le langage).
Savoir pourquoi c'est possible / impossible permet de comprendre la philosophie du langage.

[JoeChip]

utiliser les outils existants de la manière dont ils ont été pensés.

Je ne vois pas pourquoi je me limiterais à utiliser les outils de la manière dont ils ont été pensés....? c'est l'inverse de l'esprit "hacker" ça... Le conformisme est contre-productif, du moins quand t'es programmeur à ton compte... Pour se faire engager dans une grosse boîte, en revanche, je suppose que c'est plutôt bien, et que ça vaut la peine de perdre du temps exprès pour des questions de "philosophie". Sinon, ça se voit assez vite hein, encore que j'aimerais qu'on m'explique celle de php...

Perso j'ai bien tordu la "philosophie" de Java 6, et je me retrouve avec des trucs qui ressemblent à du Java 8....

[thelvin]

Je ne vois pas pourquoi je me limiterais à utiliser les outils de la manière dont ils ont été pensés....? c'est l'inverse de l'esprit "hacker" ça...

En effet, il y a le génie logiciel, mon métier, et le hacking, un jeu. Je ne vois pas de raison de se limiter à la manière dont les outils ont été prévus, mais faire l'effort de les connaître est une bonne manière de trouver ce qui marche.

Le conformisme est contre-productif, du moins quand t'es programmeur à ton compte...

Il y a conformisme et il y a connaître ce qui est productif pour quel cas, et ce qui ne l'est pas.

Mais j'ignorais que les principales bonnes pratiques et les outils retenus par ceux qui savent ce qu'ils font et le présentent, l'avaient été justement grâce à leur manque de productivité. Je dois être vraiment entouré de mauvais, alors, puisque quand je les garde c'est parce que ça bat tout le reste.

Pour se faire engager dans une grosse boîte, en revanche, je suppose que c'est plutôt bien, et que ça vaut la peine de perdre du temps exprès pour des questions de "philosophie".

C'est plus une question de "est-ce que le serveur tient, oui ou non" et "est-ce qu'on sait diagnostiquer, être réactif et s'adapter, oui ou non" que de la philosophie, mais bon.

Sinon, ça se voit assez vite hein, encore que j'aimerais qu'on m'explique celle de php...

"Je veux faire mon site web dynamique, mais ces technologies CGI à écrire en C, c'est vraiment trop compliqué. Rien n'existe de pratique pour faire ça. Je vais inventer rapidement mon propre language, bien que je n'ai aucune expérience dans le domaine, pour faire ça simplement avec une connexion base de données. Une semaine plus tard ce sera à peu près fini. Comme ce sera simple à installer et qu'un langage conçu en débutant, ça parle aux débutants, ça va se retrouver partout dans le monde, comme MS-DOS en son temps."

[JoeChip]

Je veux faire mon site web dynamique, mais ces technologies CGI à écrire en C, c'est vraiment trop compliqué. Rien n'existe de pratique pour faire ça.

Bin, ya Python, quoi. Quant au côté pratique de php, il m'a échappé. En revanche le côté qui parle aux débutants, je vois bien. Mais bon, cette connaissance de la philosophie de php n'aide pas à apprendre à programmer en php si ?

Je me demande quel sens tu donne au mot "hacker". Il arrive souvent qu'il soit plus simple d'utiliser un outil adapté pour un usage non prévu que d'en fabriquer un nouveau, juste pour qu'il soit "pensé pour" non ? La programmation, c'est - il me semble - utiliser des outils qui ont été pensés sans qu'on puisse en prévoir toutes les utilisations. Donc c'est un genre de "hack" systématisé.

j'ignorais que les principales bonnes pratiques et les outils retenus par ceux qui savent ce qu'ils font et le présentent, l'avaient été justement grâce à leur manque de productivité

Je ne comprend pas bien pourquoi tu dis ça, ni ce que ça veut dire.

Prenons un exemple simple : si on me donne un marteau pour enfoncer des clous, j'enfonce des clous avec ce marteau, peu mimporte pourquoi il a la forme qu'il a. Si en plus il peut me servir à quelque chose de non prévu, je l'utiliserai, génie menuisier ou non.

[tchize_]

Je ne vois pas pourquoi je me limiterais à utiliser les outils de la manière dont ils ont été pensés....?

Bien que tu puisse utiliser un marteau pour casser une noix, et un casse noix pour planter un clou, il vaut mieux utiliser le marteau pour planter le clou et le casse noix pour casser la noix....

C'est la même chose ici. C'est beaucoup plus performant d'utiliser le langage comme il a été prévu, plutôt que d'essayer de lui faire digérer des structure à la C++ ou du scripting à la bash. Je crois que c'était le sens de son message

Après tu peux te demander, par exemple, pourquoi on a pas de closure en java, et même raler là dessus, et bidouiller pour avoir un simili closure.... (ça c'est le casse noix pour planter le clou) ou alors si t'as vraiment l'impression que tu bosserais mieux avec les closure tu passer sur du groovy (ça c'est aller chercher le marteau)

[JoeChip]

Je ne dis pas qu'il ne faut pas utiliser les outils pour leur usage prévu, mais il y a souvent des besoins imprévus, pour lesquels il faut utiliser un outil existant s'il est adapté, même s'il n'était pas prévu pour.

Après, je suis d'accord qu'il ne faut pas plier Java pour qu'il marche comme autre chose... Et je dis aussi que peu importe pourquoi Java est différent de C++...