Variable et Attribut, Fonction et méthode

Bonjour,

J'aimerais savoir pourquoi certaines personnes disent qu'un attribut est différent d'une variable ou qu'une méthode est différente d'une fonction.

Quand on défini ou déclare une fonction en dehors d'une classe, on appel bien ça une FONCTION et non une METHODE, pourtant les 2 peuvent faire la même chose il y'aura quand même des gens qui diront qu'une méthode c'est pas une fonction et qu'une variable n'est pas un attribut.

Si quelqu'un peut affirmer ce que je dis ou au contraire m'éclairer sur ce sujet parce que pour moi déclarer une variable dans une classe ou pas ça reste une variable.

Merci ;)

"Attribut" est synonyme de "variable membre". Ce n'est pas un terme propre au C++, mais du monde objet. Il ne porte pas à ambiguïté, même si depuis le C++11 nous avons officiellement des attributs qui désignent tout autre chose.

"Méthode" est un terme impropre en C++. Pour la plupart des gens cela signifie "fonction membre". Dans le TC++PL, Stroustrup définit "méthode" comme "fonction membre virtuelle". Si on se rapproche de la définition UML où "méthode" est une "spécialisation d'opération", la définition de Stroustrup me parait plus juste. De fait, je me force à ne jamais utiliser "méthode" dans le contexte C++ pour désigner des fonctions. C'est donc "fonction" au sens large, "fonction libre" pour les hors classe, "fonction membre" pour les définies dans des classes. (Plus tous les autres machins appelables: foncteurs, lambdas...)

Merci pour ta réponse, dans ce cas nous sommes bien d'accord, un attribut est une variable membre d'une classe et une méthode est une fonction membre d'une classe mais ça reste strictement la même chose non ? Une fonction qu'elle soit membre d'une classe ou pas reste pour moi une fonction, de même pour une variable.

Il y a des subtilités, les "attributs" au sens POO sont liés à un objet de la classe dont on parle.
De même les méthodes ont un paramètre caché, this, qui est l'objet sur laquelle on l'appelle.

Et Luc Hermitte te dit justement que ce ne sont pas des termes adaptés au C++.
En C++, tu trouveras des attributs tels que [[noreturn]] et le terme méthode n'est pas utilisé dans la norme. (on parle de fonction membre non-statique)

Citation:

---

Envoyé par LuNaTiC93

Merci pour ta réponse, dans ce cas nous sommes bien d'accord, une attribut est une variable membre d'une classe et une méthode est une fonction membre d'une classe mais ça reste strictement la même chose non ? Une fonction qu'elle soit membre d'une classe ou pas reste pour moi une fonction, de même pour une variable.

---

Presque, une "méthode" est une "fonction membre virtuelle" si on suit le vocabulaire du créateur du langage. En ce qui me concerne, il a créé le langage, donc son vocabulaire est le vocabulaire officiel dans le contexte de ce langage.

Et sinon, une fonction qu'elle soit membre ou non, cela reste en effet une fonction. La subtilité est qu'une fonction membre non-statique dispose d'un paramètre implicite: celui de l'objet sur laquelle la fonction s'appelle.

Pour les curieux, renseignez-vous sur l'UCS (Uniform Call Syntax). Comme quoi, tout cela, ce n'est jamais que du sucre syntaxique.

PS: Enfin un attribut au sens objet est tout autant une variable qu'un champ de structure l'est.

Citation:

---

Envoyé par ternel

Il y a des subtilités, les "attributs" au sens POO sont liés à un objet de la classe dont on parle.
De même les méthodes ont un paramètre caché, this, qui est l'objet sur laquelle on l'appelle.

Et Luc Hermitte te dit justement que ce ne sont pas des termes adaptés au C++.
En C++, tu trouveras des attributs tels que [[noreturn]] et le terme méthode n'est pas utilisé dans la norme. (on parle de fonction membre non-statique)

---

J'avais bien compris que le mot attribut n'était pas propre au C++ mais à la notion de POO peut importe le langage. Mais on est au final d'accord pour dire qu'une variable qu'elle soit membre d'une classe ou pas reste une variable, elle n'a rien de différent, on l'appelle attribut ça permet d'ailleurs de savoir qu'elle fait partie d'une classe mais au final son utilité est la même et c'est la même chose pour les fonctions. C'était juste pour affirmer certaines points parce que lorsque tu rencontres des devs qui te sortent "une méthode c'est pas une fonction, c'est pas pareil" mais qui sont incapables de t'expliquer pourquoi c'est assez énervant.

Merci pour vos réponses ;)

AMA, beaucoup font un blocage sur la syntaxe sans avoir le moindre recul.

D'abord pourquoi la "méthode" ne devrait être liée qu'à un seul objet? Quid du multi-dispatch ? Quid de CLOS, un des tous premiers langages OO (d'ailleurs Alan Kay, le premier à avoir dit "object oriented", et donc l'inventeur de la définition d'une certaine façon valide que CLOS est OO, à contrario de C++, Java et bien d'autres). Le truc intéressant dans CLOS, c'est que la syntaxe d'appel est "(f x y)". Autre détail, il est fonctionnel et non impératif...

C'est le gros problème avec beaucoup de devs, ils n'ont pas de recul ou même de connaissances de bas niveau donc va leur expliquer qu'une variable membre ou pas de type int que tu l'appel attribut ou variable, il y'aura dans tous les cas une allocation mémoire de 4 bytes et rien de plus. Mais certains te diront toujours "c'est pas pareil" en pensant avoir la science infuse alors que c'est tout le contraire :?

Citation:

---

C'est le gros problème avec beaucoup de devs, ils n'ont pas de recul ou même de connaissances de bas niveau donc va leur expliquer qu'une variable membre ou pas de type int que tu l'appel attribut ou variable, il y'aura dans tous les cas une allocation mémoire de 4 bytes et rien de plus. Mais certains te diront toujours "c'est pas pareil" en pensant avoir la science infuse alors que c'est tout le contraire

---

Gars, c'est pas pareil, et c'est toi qui n'a pas les connaissances de bas niveau pour dire aux autres comment ils doivent parler. :weird:

Moi, je m'adapte à mes interlocuteurs, attributs/champs/variables membres non statiques, méthodes/fonctions/fonction libre, je m'en cogne tant que tous les intervenants sont d'accord sur les choses désignées par ces termes.

Mais quand on commence à me dire des conneries de haut, je remets les points sur les i, parce que faut pas pousser mémé dans les orties.

Un int n'a pas de taille défini dans la norme, même pire, elle doit s'adapter à la plateforme cible, donc en 32bits et en 64bits, c'est pas la même longueur.
Et en sachant que les compilateurs et suivant les options (jeu d'instruction autorisée, niveau d'optimisation, etc...) sont absolument libre de choisir la taille qu'ils veulent.
Et c'est aussi sans compter sur le padding dans les layout mémoire, etc...

Donc, Quand on est sujet à l'effet Dunning-Kruger (https://fr.wikipedia.org/wiki/Effet_Dunning-Kruger), il faut suivre l'adage de Gustave Parking :

Citation:

---

Des fois, il vaut mieux ne rien dire et passer pour un con que de l'ouvrir et ne laisser aucun doute à ce sujet.

---

J'ai dit que le type int avait une taille définie dans une norme ? "Mais quand on commence à me dire des conneries de haut, je remets les points sur les i", je ne t'ai même pas parlé, pour le moment ton commentaire n'a rien de constructif, si une méthode est différent d'une fonction ou qu'un attribut est différent d'une variable explique le au lieu d'insulter les autres et de péter plus haut que ton cul.

Citation:

---

i une méthode est différent d'une fonction ou qu'un attribut est différent d'une variable explique

---

Comme je l'ai déjà indiqué, le problème n'est pas dû au vocabulaire.
Si tu veux des définitions d'attribut en C++, regardes la documentation et tu verras que cela n'a rien à voir avec un champ/variable membre d'instance.
Mais le problème n'est pas là.
Une méthode en C++, ça n'existe pas dans la norme, mais on sent fout, le problème n'est pas là.

Le problème, c'est que tu dis n'importe quoi et que tu te justifies juste en prétendant que c'est un problème de vocabulaire, NON.

Citation:

---

type int que tu l'appel attribut ou variable, il y'aura dans tous les cas une allocation mémoire de 4 bytes et rien de plus

---

Tu peux prendre toutes les interprétations possibles des mots, ça sera toujours une connerie.

La taille d'un int n'est pas constante, et l'utilisation du padding fait qu'un int peut faire allouer une taille qui n'est même pas fixe dans un même programme.

Tu peux prendre ton assertion dans le sens que tu veux, elle sera toujours fausse, TOUJOURS.

Tu dis au final la même chose que j'ai dit, une méthode n'est pas définie dans la norme pour le C++ pourtant il y'a des milliers de devs ou de profs qui te diront que c'est une méthode et pas une fonction et que c'est pas pareil sans apporter d'arguments valables.

Sans utiliser de padding ou d'optimisation dans le compilateur, le type int tout simplement est généralement dans la plupart des compilateurs représenté sur 4 bytes, je parle bien du type int et non du _int64. Dans le compilateur Visual C++ ( https://msdn.microsoft.com/fr-fr/library/s3f49ktz.aspx ) si tu déclares une variable de type int il t'allouera en mémoire 4 bytes et je me servais de cet exemple pour appuyer mes arguments sur la différence entre un attribut d'une classe et une variable.

Ton agressivité me fait juste rire au final tu n'apportes rien de viable pour enrichir la discussion contrairement à Luc Hermitte.

Surtout que le terme "méthode" ne permet pas de savoir si c'est une fonction membre ou une procédure membre :mrgreen: :mrgreen:

Citation:

---

Envoyé par foetus

Surtout que le terme "méthode" ne permet pas de savoir si c'est une fonction membre ou une procédure membre :mrgreen: :mrgreen:

---

Dans tous les cas mon but était de clarifier certains détails, même si la majorité des gens appelent une fonction membre "méthode" y'a pas de soucis, mais quand il y'a des gens qui viennent dire que c'est pas pareil ou même que ça n'a rien à voir...

Dans un autre sens :mrgreen:, ils ont un chouïa raison : une méthode doit être utilisée via un objet et plus directement.

En C++, on ne pas faire une truc comme using class Tartampion; comme on peut le faire avec un namespace.

Et l'autre truc en C++, ce sont les pointeurs de méthode : tu es obligé de préciser/ spécifier la classe, sinon le compilateur le prend pour un pointeur de fonction/ procédure comme en C



Édit : Ah flûte j'ai écrit 'pointeur'. Une armée va me tomber dessus pour me dire toutes les techniques modernes pour faire la même chose Allez je m'auto-fouettes pour la peine :sm:

Oui mais c'est bien la seule différence notable entre une fonction non membre et une fonction membre d'une classe, il faut passer par un objet pour utiliser la dite fonction ou accéder aux variables de la classe mais dans le principe c'est la même chose non ?

C'est juste sur ça que je voulais faire le point parce que j'ai eu des profs en C++ qui te disent qu'une fonction dans une classe c'est une méthode et que c'est différent sans apporter plus de précisions

Ho, les gars, s'il vous plait... commencez pas à vous engueuler, car on va pas tarder à distribuer les points Godwin, si ca continue!

Bonjour,

Je viens de faire une recherche dans N4659 (C++17 final draft) et il y a bien quelques rares endroits où le mot method est utilisé.
Par exemple, on peut lire : « For a basic_string_view str, any operation that invalidates a pointer in the range [str.data(),
str.data() + str.size()) invalidates pointers, iterators, and references returned from str’s methods. »

Le mot method n'était pas défini dans ce document. En tout cas, dans les exemples où je l'ai vu, il désignait des fonctions membres non virtuelles. Donc, selon ce document, on ne peut pas dire qu'une méthode est forcément virtuelle.

En programmation orientée objet, une méthode, c'est une fonction associée à une classe. Elle a accès aux attributs, en général privés, de la classe.
A mon avis, en C++, parmi les fonctions qui peuvent modéliser des méthodes d'une classe, il y a les fonctions membres de la classe, mais potentiellement aussi des fonctions amies de la classe.

Cela dit, dans la norme, le vocabulaire du C++ s'écarte parfois de celui de la programmation orientée objet. Par exemple, en C++, un objet n'est pas forcément une instance de classe.
Plus de détails : http://en.cppreference.com/w/cpp/language/type

Le vocabulaire est quelque fois ambigu mais globalement une fonction qu'elle soit membre d'une classe ou pas reste une fonction non ?

Code:

---

1 2 3 4 5 6 7 8 9

int MaFonction() { return 0; }   int A::MaFonction() { return 0; }

---

Entre ces 2 fonctions il n'y a rien de différent si ce n'est qu'une est membre de la classe A et que l'autre ne l'est pas. Bon il y'en a une qui aura besoin d'une instance pour pouvoir être appelée mais dans la globalité les 2 feront la même chose. Pourtant il y'a encore des devs pour dire qu'une méthode de classe est pas une fonction que ça n'a rien à voir.

Citation:

---

Envoyé par LuNaTiC93

Pourtant il y'a encore des devs pour dire qu'une méthode de classe est pas une fonction que ça n'a rien à voir.

---

Et après ? Combien de pages te faut-il pour comprendre qu'on s'en moque pas mal ? c'est juste du vocabulaire et chacun a un peu le sien.
En anglais on utilisait method. Et member method. Tout comme on dit variable ou member variable, voire juste member en fait.
Dans l'ensemble tout le monde se comprend, c'est tout ce qui importe. Le reste, y compris ce sujet, n'est que chipotage à je ne sais quelle fin.
Attends-tu qu'on te dise que oui tu as raison et tout le monde autour de toi a tord ? C'est pas près d'arriver imo :weird:
méthode, fonction, procédure; variable, membre, attribut et surement d'autres peuvent être trouvés

Pas de tout tu fais fausse route, j'étais juste là pour demander justement parce qu'au final il y'a tellement de monde qui dit que ça n'a rien à voir que je commençais à avoir des doutes. Je m'en moque du vocabulaire du moment qu'on se comprends quand on parle techniquement.

Alors parce que d'autres gens n'ont pas l'air d'utiliser le même vocabulaire que toi, tu nous demande notre avis?
Pourquoi ne pas simplement prendre le temps de définir le vocabulaire avec eux.

@LuNaTiC93, pour faire simple, toutes tes remarques autres que sur l'ambiguïté du vocabulaire sont des assertions et elles sont complètement fausses.

La taille d'un int, c'est pas 4.
Prends ce code et compile en 64 bits ce code :

Code:

---

1 2 3 4 5 6

int main() { int toto;   std::cout<< sizeof(toto); }

---

Une fonction membre/ méthode membre, ça n'a pas grand-chose de commun avec une fonction libre car les conventions d'appels (donc les "arguments" disponibles) et la résolution de nom n'ont absolument rien de commun.
(Et une fonction membre virtuelle et une fonction membre non-virtuelle ont encore plus de différence entre elles qu'une fonction membre non-virtuelle et une fonction libre)
Si ton interlocuteur, ton prof. je te le rappelle, fait la distinction, c'est que pour lui, c'est des différence qui ont de l'importance dans la suite de ces explications/enseignements.
Si tu ne vois pas les différences, admets que tu les ignorent et demandes à ton interlocuteur quelles différences tu dois connaitre pour que les informations qu'il doit te transmette soit correctement assimilées.

Citation:

---

Envoyé par ternel

Alors parce que d'autres gens n'ont pas l'air d'utiliser le même vocabulaire que toi, tu nous demande notre avis?
Pourquoi ne pas simplement prendre le temps de définir le vocabulaire avec eux.

---

Relis ce que j'ai du tout à l'heure, qu'ils n'utilisent pas le même vocabulaire je m'en contre fou, mais quand on leur demande une explication eux même ne sont pas capable d'en fournir une pour définir la différence.

Je demandais un avis et alors ? Ce n'est pas un forum ici ? On est pas là pour échanger ou partager nos connaissances ? La réaction de la plupart des membres ici est typiquement française, prendre de haut et péter plus haut que son cul, pour avoir passé 7 ans sur des forums ricains la mentalité est tout autre.

Citation:

---

Envoyé par bacelar

@LuNaTiC93, pour faire simple, toutes tes remarques autres que sur l'ambiguïté du vocabulaire sont des assertions et elles sont complètement fausses.

La taille d'un int, c'est pas 4.
Prends ce code et compile en 64 bits ce code :

Code:

---

1 2 3 4 5 6

int main() { int toto;   std::cout<< sizeof(toto); }

---

Une fonction membre/ méthode membre, ça n'a pas grand-chose de commun avec une fonction libre car les conventions d'appels (donc les "arguments" disponibles) et la résolution de nom n'ont absolument rien de commun.
(Et une fonction membre virtuelle et une fonction membre non-virtuelle ont encore plus de différence entre elles qu'une fonction membre non-virtuelle et une fonction libre)
Si ton interlocuteur, ton prof. je te le rappelle, fait la distinction, c'est que pour lui, c'est des différence qui ont de l'importance dans la suite de ces explications/enseignements.
Si tu ne vois pas les différences, admets que tu les ignorent et demandes à ton interlocuteur quelles différences tu dois connaitre pour que les informations qu'il doit te transmette soit correctement assimilées.

---

Enfin quelque chose de constructif de ta part c'est fort étonnant. Si tu n'as toujours pas compris que mon exemple pour l'allocation mémoire pour un entier était là pour appuyer mes arguments :roll:

J'ai rarement vu ça dans ma vie, je suis là pour demander les différences si il y'en a et mise à part la réponse de Luc qui était constructive je ne vois que de l'agressivité et de la vantardise de la part de membres qui ont plus de 40 ans et des années d'expérience derrière eux.

Un forum c'est fait pour échanger et non pour prendre de haut les gens qui posent des questions même si tu peux trouver ma question inutile au final aucun membre jusqu'ici ne s'accorde pour définir la différence entre une "méthode" ou une "fonction".

N'oubli pas que toi comme moi nous n'avons rien inventé, je suis là pour apprendre et comprendre toutes les compléxités du C++ et c'est normal de poser une question quand on a un doute sur quelque chose non ?

Apprends-nous à être de bon gros ricains, élevés aux grains, mais on t'a déjà donné des arguments contre tes assertions, mais tu ne t'attaques qu'à la forme.
Donc, non, un int n'a pas 4 de longueur, il a même très souvent 8 comme longueur quand on compile en 64 bits.
Et les mécanismes d'appel d'une fonction membre non-statique ajoutent un argument "this", et la résolution des noms de variables prend en compte prioritairement les champs de la classe (après les variables locales), qui fait que le code d'une fonction libre et d'une fonction membre non-statique sont assez/très différents.

Beaucoup des personnes que tu rambardes travaillent ou ont travaillés hors de l'hexagone, et fréquentent assidument les forums anglophones (et pas que) alors arrêtes de nous prendre pour des jambons.

Si tu insistes sur la forme et le vocabulaire, je te considèrerais comme un troll et je demanderais à ne pas te nourrir.

Il n'y pas pire aveugle que celui qui ne veut pas voir.

Les forums anglohones ont une autre mentalité que ça te plaise ou non mon gars. A part répéter qu'un int fait 64 bits quand on compile en 64bits tu n'as donné aucun argument, tu as juste été agressif depuis le début. Contrairement à toi je ne rambarde personne, je suis juste là pour discuter tranquillement, me dire ça c'est l'hôpital qui se fout de la charité.

Le sujet est passé en "résolu", ce n'est plus la peine de me répondre, je sais que tu aimes bien péter plus haut que ton cul et prendre les gens de haut mais ça n'est pas nécessaire.

Et avant de faire des citations philosophiques relis toi et fait attention à ton orthographe tu perds toute crédibilité :mouarf:

Citation:

---

Envoyé par bacelar

a-Une fonction membre/ méthode membre, ça n'a pas grand-chose de commun avec une fonction libre car les conventions d'appels (donc les "arguments" disponibles) et la résolution de nom n'ont absolument rien de commun.

b- Si ton interlocuteur, ton prof. je te le rappelle, fait la distinction, c'est que pour lui, c'est des différence qui ont de l'importance dans la suite de ces explications/enseignements.
Si tu ne vois pas les différences, admets que tu les ignorent et demandes à ton interlocuteur quelles différences tu dois connaitre pour que les informations qu'il doit te transmette soit correctement assimilées.

---

a- Je ne suis pas trop d'accord là dessus.
Membre et libre avec un argument, c'est pour moi exactement la même chose sur les plans techniques (assembleur) et conceptuel (kick(dog) et dog.kick() c'est pareil, ce n'est que de la syntaxe; c'est bien pour ça que j'ai montré la syntaxe de CLOS). Les papiers sur l'UCS ne font que me confirmer cette vision.
OK, il va y avoir en C++ des différences dans les résolutions d'appels. Et c'est ce qui a posé problèmes pour l'acceptation de l'UCS. Les différences sont encore plus subtiles quand on introduit l'amitié: le libre se rapproche encore plus du membre.

Dans tous les cas, cela ne mérite pas que l'on se prenne le choux sur ce sujet.

b- hum... Étant de plus en plus dubitatif quant à la compréhension et l'enseignement de l'objet... disons que je vais me garder de critiquer.
Si par contre le prof parle de messages et que les méthodes sont le moyen technique pour mettre en œuvre les messages... là on commence à introduire des différences subtiles qui ne sont pas vides de sens. Mais ce n'est pas forcément facile à expliquer vu que le côté pratique finit toujours par prendre le dessus sur le côté théorique dans les langages que l'on manipule et qui ne sont pas orientés messages.

Citation:

---

a-Une fonction membre/ méthode membre, ça n'a pas grand-chose de commun avec une fonction libre car les conventions d'appels (donc les "arguments" disponibles) et la résolution de nom n'ont absolument rien de commun.

---

Citation:

---

Envoyé par Luc Hermitte

a- Je ne suis pas trop d'accord là dessus.
Membre et libre avec un argument, c'est pour moi exactement la même chose sur les plans techniques (assembleur) et conceptuel (kick(dog) et dog.kick() c'est pareil, ce n'est que de la syntaxe; c'est bien pour ça que j'ai montré la syntaxe de CLOS). Les papiers sur l'UCS ne font que me confirmer cette vision.
OK, il va y avoir en C++ des différences dans les résolutions d'appels. Et c'est ce qui a posé problèmes pour l'acceptation de l'UCS. Les différences sont encore plus subtiles quand on introduit l'amitié: le libre se rapproche encore plus du membre.

---

Je n'en disconviens pas, mais si l'interlocuteur doit enchainer sur les conventions d'appel de fonction __thiscall, __std ou _cdecl sur architecture x86, ne pas faire la différence entre ces "machins", ça va être compliqué. ;)

Citation:

---

Envoyé par Luc Hermitte

Dans tous les cas, cela ne mérite pas que l'on se prenne le choux sur ce sujet.

---

T'as raison, qu'il reste dans sa bulle.

Citation:

---

Envoyé par Luc Hermitte

a- Je ne suis pas trop d'accord là dessus.
Membre et libre avec un argument, c'est pour moi exactement la même chose sur les plans techniques (assembleur) et conceptuel (kick(dog) et dog.kick() c'est pareil, ce n'est que de la syntaxe; c'est bien pour ça que j'ai montré la syntaxe de CLOS). Les papiers sur l'UCS ne font que me confirmer cette vision.
OK, il va y avoir en C++ des différences dans les résolutions d'appels. Et c'est ce qui a posé problèmes pour l'acceptation de l'UCS. Les différences sont encore plus subtiles quand on introduit l'amitié: le libre se rapproche encore plus du membre.

Dans tous les cas, cela ne mérite pas que l'on se prenne le choux sur ce sujet.

b- hum... Étant de plus en plus dubitatif quant à la compréhension et l'enseignement de l'objet... disons que je vais me garder de critiquer.
Si par contre le prof parle de messages et que les méthodes sont le moyen technique pour mettre en œuvre les messages... là on commence à introduire des différences subtiles qui ne sont pas vides de sens. Mais ce n'est pas forcément facile à expliquer vu que le côté pratique finit toujours par prendre le dessus sur le côté théorique dans les langages que l'on manipule et qui ne sont pas orientés messages.

---

Merci pour ces explications, ça me fait plaisir de voir quelqu'un qui prend le temps d'expliquer et surtout qui ne fait pas preuve d'agressivité.

Bon, alors, pour être clair:

Oui, un attribut est une variable et oui, une méthode est une fonction.

Mais le fait est que, quand elle fait partie d'un "agglomérat" (comme cela, on reprend struct, class et même union), une variable ou une fonction a besoin de cet agglomérat, soit pour exister (quand elle n'est pas statique) soit pour être simplement reconnue comme telle par le compilateur (lorsqu'elle est statique).

Les gens qui hurlent à la différence ont donc pris deux éléments en compte:

1. une fonction ou une variable qui fait partie d'un agglomérat subit de grosses restrictions par rapport à une fonction ou à une variable qui n'en fait pas partie et
2. il est donc "cohérent" de permettre de faire la distinction entre les deux, ce qui implique l'utilisation d'un terme différent

Avec l'utilisation de termes différents ou spécifiques comme "donnée / fonction membre" ou comme "attribut / méthode", on se donne la possibilité d'éviter toute ambiguïté.

Mais, du coup, on se rend compte que si tout attribut (variable /donnée membre) est une variable, et que toute méthode (fonction membre) est une fonction, l'inverse n'est pas forcément vrai, car une variable (sous entendu "variable locale") ou une fonction (sous entendu "fonction libre") n'est pas forcément soumise aux mêmes restrictions qu'un attribut ou qu'une méthode.

Après, on peut ne pas partager leur avis, mais on est bien obligé d'admettre que leur logique est sans faille; aussi bien dans la décision de faire une distinction entre les différents termes que dans celle de faire respecter (et si possible comprendre) cette distinction.

Pour le reste, j'ai envie de dire que ce n'est qu'une question de conventions et de "savoir vivre":

Tu peux décider (ou non) de respecter les conventions, mais, si tu décides de ne pas les respecter, il ne faudra pas t'étonner si tu n'est pas toujours compris et, surtout,

Quand tu décides de t'intégrer dans un groupe, si tu veux que l'intégration se passe bien, il est préférable d'en respecter les habitudes et les coutumes (à moins, bien sur, qu'elle ne choquent tes propres croyances ou ta propre sensibilité).

Or, il se fait que, si beaucoup de développeurs ne se choqueront nullement de t'entendre parler de fonction lorsqu'il s'agit de fonction membre / méthode, ils peuvent facilement être choqués s'il t'entendent parler de méthode au sujet d'une "fonction libre".

Tu peux, bien sur, être persuadé qu'ils ont tord, mais, à partir du moment où je ne vois pas en quoi cela pourrait choquer tes propres croyances ou ta propre sensibilité, le mieux que tu aies à faire est encore d'en prendre acte, et d'agir en conséquence. Ne crois tu pas :question:

Merci pour ton explication elle est au top. Comme tu l'as dit le fait de donner un nom différent aux fonctions membre et aux variables membre permet d'éviter toute ambiguité et ça me convient parfaitement, je n'étais pas là pour imposer une quelconque croyance bien au contraire j'étais là justement pour demander l'avis de développeurs expérimentés.

Les quelques devs que j'ai vu IRL n'ont pas su m'expliquer la différence si ce n'est dire "c'est pas pareil c'est tout". Et il est évident que je m'adapte à mon interlocuteur quand je discute, ce qui m'a fait ouvrir ce topic était justement un interlocuteur qui lui n'a pas su s'adapter à mon vocabulaire et qui me disait que ça n'était pas pareil sans apporter de précision :?

Merci pour ta réponse ;)

Ce que j'ai lu entre les lignes, c'était limite le contraire d'ailleurs: des développeurs qui tenaient à dire que les méthodes ne sont pas des fonctions sans savoir expliquer pourquoi. Je me trompe?

<Car si c'est bien le cas> Mais pourquoi diable tout ce bruit et débat depuis hier? Car pour le coup, les gars en face, c'est des boulets qui ont des classifications à l'ouest. Ils sont au niveau de dire que les manchots ne sont pas des oiseaux car ils n'ont pas la liberté de voler. Franchement?</>

On passe à autre chose?

Citation:

---

Envoyé par Luc Hermitte

Ce que j'ai lu entre les lignes, c'était limite le contraire d'ailleurs: des développeurs qui tenaient à dire que les méthodes ne sont pas des fonctions sans savoir expliquer pourquoi. Je me trompe?

---

En gros, ce sont les agneaux de Panurge, qui ont accepté ce que les autres leur disaient sans se poser de question.

L'un dans l'autre, je préfère l'approche de LuNaTiC93 qui en demande la raison afin d'au moins avoir une chance de la comprendre ;)