Discussion :

[wafiwafi]

Bonjour,
J’aimerais avoir votre réponse sur l’interrogation suivante :
Considérons une méthode qui retourne un objet a d’un type A.
Est-ce que cette dernière retourne l’adresse de l’objet a ou l’objet lui-même ?
Car, si je veux remplacer l’objet a par l’objet b (également de type A), on ne peut pas prétendre l’affectation :
a=b
Merci à vous

[thelvin]

Est-ce que cette dernière retourne l’adresse de l’objet a ou l’objet lui-même ?

Vu le reste de ta question, disons l'objet lui-même.

Mais ce n'est pas comme ça qu'il faut le dire. En Java, les expressions de type objet, sont toujours, toujours, ce que Java appelle des références vers un objet. Ce que Java appelle une référence n'est, ni une addresse, ni un pointeur, ni ce que C++ et d'autres appellent une référence, ni l'objet lui-même. C'est encore un autre concept. Ça ressemble à un pointeur. Et ça ressemble à l'objet lui-même.

on ne peut pas prétendre l’affectation

Ni dans ce cas, ni dans aucun cas en français, on ne prétend pas une affectation. À la limite on peut prétendre que quelqu'un a été affecté à une mission ou à un poste.

Code :

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

a=b

Cela ne changera, en effet, rien au reste du code qui utilisait déjà a : cette affectation ne les affectera pas et ils utiliseront toujours le même objet.

En cela, ça se comporte comme un pointeur. Un pointeur qu'on ne peut pas déréférencer pour affectation (puisqu'aucune syntaxe n'existe pour.)

[wafiwafi]

Tout d'abord, merci pour ta réponse.

Quand je crée un objet c de type A, je peux procéder à une affectation :
c=b
sans aucun problème. L'objet c prend les attributs de celui de b.
Par contre l'objet a retourné par la méthode M() (voir message précédent) l'affectation M()=b est rejeté. C'est cela qui m'interpelle.

Cela ne changera, en effet, rien au reste du code qui utilisait déjà a : cette affectation ne les affectera pas et ils utiliseront toujours le même objet.

En cela, ça se comporte comme un pointeur. Un pointeur qu'on ne peut pas déréférencer pour affectation (puisqu'aucune syntaxe n'existe pour.)

ok, c'est clair!

Ni dans ce cas, ni dans aucun cas en français, on ne prétend pas une affectation. À la limite on peut prétendre que quelqu'un a été affecté à une mission ou à un poste.

j'ai dit : prétendre l'affectation du point de vue informatique car, dans mon contexte, remplacer les attributs de l'objet a ,retournée par la méthode, par ceux de l'objet b m'arrangeait, et si c'était possible, je l'aurait fait.
Par simple curiosité, pourquoi cela te dérangeait?
"prétendre=désirer " dans mon cas.

Merci pour tes explications.

[thelvin]

Quand je crée un objet c de type A, je peux procéder à une affectation :
c=b
sans aucun problème. L'objet c prend les attributs de celui de b.

Non. Avant cette affectation, la variable c désignait un objet, que nous appellerons gamma.
La variable b désigne un objet que nous appellerons béta.

Après cette affectation, la variable c ne désigne plus l'objet gamma. La variable c désigne l'objet que la variable b désigne : béta.
L'objet gamma, lui, ne subit aucune modification et continue de vivre sa vie.
Bref, cette affectation marche comme des pointeurs : c pointait un objet, et maintenant c pointe un autre objet. D'ailleurs on peut affecter null à c : ne pointer aucun objet.

Si, à un moment, plus aucune variable, plus aucun tableau ne le désigne, bref s'il n'est plus référencé et donc plus utilisé, alors le garbage collector viendra désallouer l'objet gamma en temps et en heure.

Par contre l'objet a retourné par la méthode M() (voir message précédent) l'affectation M()=b est rejeté. C'est cela qui m'interpelle.

Cela n'aurait aucun sens, puisqu'une affectation ne change pas les objets eux-mêmes, mais change vers quel objet on pointe.
Par conséquent, on ne peut affecter qu'une variable ou un emplacement de tableau.
Tout comme pour les types de base comme char et int, où ça n'aurait pas de sens non plus d'affecter autre chose.

j'ai dit : prétendre l'affectation du point de vue informatique

Ce qui, justement, n'existe pas, ne veut rien dire, et on ne peut pas facilement deviner à quoi tu penses en inventant ces mots.
On invente tous des mots quand il y a besoin, mais de préférence de sorte à simplifier les choses, pas à les compliquer.

Par simple curiosité, pourquoi cela te dérangeait?

Parce que ces questions sont déjà suffisamment confuses par nature, pour les gens qui les posent. Nous n'avons pas besoin d'ajouter encore plus de confusion avec des mots qui n'ont pas de sens établi et qu'on ne peut même pas deviner avec confiance.

[wafiwafi]

tout est clair.
Merci pour toutes ces réponses pertinentes.