Est-ce mal de parler de «méthodes» C ++ (par opposition à «fonctions membres»)?

19

Je comprends que selon la spécification C ++, il n'y a pas de "méthode", et certains (beaucoup? La plupart?) Programmeurs C ++ considèrent la "méthode" comme un Java-isme. D'un autre côté, même sur un forum C ++, les gens semblent parler de méthodes sans se contracter. Je recherche des conventions connues ou des pratiques courantes concernant cette terminologie.

Je documente une API qui a à la fois des versions C ++ et Java. Les développeurs ont en fait conservé les noms de classe et de méthode / fonction membre entre les deux, probablement pour des raisons de portage et de test. Pour cette raison, une partie de ce qui doit être documenté au sujet de ces API se situe "au-dessus" du choix de la langue; J'ai besoin de pouvoir parler en général des Foos et Bars, avec leurs méthodes baz () et mumble () ...?

Si je parle de méthodes que les programmeurs Java considéreront comme naturelles et, semble-t-il, les programmeurs C ++ comprendront probablement mais certains considéreront que c'est incorrect. Ma question est: à quel point est-ce odieux dans la pratique ? Comment les fonctions membres C ++ sont-elles classiquement parlées dans des contextes "POO généraux", par opposition à des contextes spécifiques à C ++? Existe-t-il une meilleure façon de parler des fonctions membres d'une manière qui n'est incorrecte pour aucune langue? ("Fonctions membres" est un peu bavard.)

Ce n'est pas un sondage d'opinion; J'essaie de déterminer s'il existe des conventions ou des pratiques courantes pour résoudre ce problème.

Je suis au courant de cette question , mais elle concerne la POO en général et ne pose pas de questions sur des langues spécifiques.

object-oriented c++ terminology Monica Cellio
la source
J'ai lu le centre d'aide et passé en revue la liste des balises avant de poser cette question. Ai-je fait quelque chose de mal en demandant ceci ici?
Monica Cellio
Le vote serré que vous avez est principalement basé sur l'opinion, ce qui pourrait bien être .. Je ne sais pas dans quelle mesure cela peut fonctionner sur un site SE simplement parce qu'il est difficile de dire avec autorité si les gens seront irrités contre vous et à quelle ampleur ils le seront. être .. Une personne peut penser que c'est tout à fait correct et une autre pense que c'est une terrible violation de la terminologie, tout comme vous l'avez décrit dans le Q- à cause de cela, c'est relativement un genre d'opinion seulement
Jimmy Hoffa
2
Le concept OOP de méthodes correspondrait le mieux à la «fonction de membre virtuel» en C ++, mais c'est la même chose. Il y a pire terminologie du côté de Java, comme les «méthodes statiques» qui ne sont pas des méthodes mais des fonctions. Continuez à utiliser le mot «méthode» indépendant du langage, et tout le monde comprendra ce que vous voulez dire. Si quelqu'un insiste sur le fait que C ++ n'a pas de méthodes, c'est juste une erreur de fait et une perte de vélo incroyablement ennuyeuse.
amon
1
@JimmyHoffa est-ce mieux?
Monica Cellio
3
Appelez-les simplement méthodes dans votre doc API multilingue. Vous pouvez inclure une phrase dans le texte d'introduction comme «Pour essayer de rester indépendant du langage de programmation, cette documentation API utilisera le terme méthode pour faire référence aux fonctions membres C ++».
Brandin

Réponses:

11

Pourquoi ne pas inclure une explication (tout comme vous l'avez fait dans votre question) dans la partie introductive de la documentation, par exemple une section Conventions ? Vous pourriez alors expliquer que le terme "méthode", tel qu'il est utilisé dans votre documentation, est utilisé dans le sens générique de méthode (Java), fonction membre (C ++), ... puisque la documentation s'applique à toutes les implémentations.

sceaj
la source
C'est ce que j'ai fait et jusqu'à présent, les gens semblent d'accord. Merci pour la suggestion.
Monica Cellio
15

Eh bien, vous n'allez pas vous faire exécuter.

La plainte dans le monde C ++ n'est pas une correction pédante: c'est une ambiguïté. Il existe tellement de types de «méthodes» différentes dans le désert, selon le domaine dont vous parlez, qu'un certain nombre d'entre nous préfèrent s'en tenir à la terminologie standard pour éviter des malentendus plus tard. Cela signifie, grosso modo, "fonction statique / [non statique] [pure] virtuelle / [non virtuelle] / [libre]".

Si vous écrivez plutôt "méthode" dans votre documentation, certains programmeurs C ++ peuvent se plaindre que ce dont vous parlez n'est pas vraiment clair, ou craindre que si vous n'êtes pas familier avec cette convention C ++, quels autres vous manquent?

Mais je suis sûr qu'il y a des millions de programmeurs C ++ professionnels qui eux-mêmes n'ont aucune idée que c'est même une chose. C'est un grand vieux monde.

Vous n'allez pas vous faire exécuter pour ça.

Courses de légèreté avec Monica
la source
3

Eiffel les appelle routines ou fonctionnalités , C ++ les appelle fonctions membres et (presque) tous les autres langages OO jamais créés dans toute l'histoire de l'informatique, avant et après que C ++ les appelle méthodes , de sorte que ce dernier terme devrait généralement être compris même par Les programmeurs C ++ (et Eiffel), à moins qu'ils n'aient vraiment jamais entendu parler de Simula, Smalltalk, Self, Objective-C, Newspeak, Java, C #, VB.NET, PHP, Python, Ruby, ECMAScript / JavaScript, Scala, CoffeeScript,…

Jörg W Mittag
la source
Sauf que le fait est qu'ils signifient souvent des choses subtilement différentes dans ces domaines. C'est pourquoi les PO demandent s'il vaut mieux s'en tenir à la terminologie spécifique au domaine, et pourquoi la bonne réponse est "oui" ...
Courses de légèreté avec Monica
Je viens de réaliser que vous avez prouvé mon point de vue en citant JavaScript, qui n'a même pas de classes (son OO est basé sur un prototype). Alors, comment les méthodes JavaScript peuvent-elles être identiques aux méthodes ailleurs? L'intelligibilité mutuelle que vous revendiquez n'existe pas réellement.
Courses de légèreté avec Monica
La POO basée sur un prototype ne fait aucune différence. La POO est basée sur la notion que les objets communiquent via des messages (comme les serveurs qui s'envoient des requêtes), et une méthode fait référence à la manière (méthode) par laquelle un objet particulier répond à un message donné. Le prototype OO ne fait qu'une différence en ce qui concerne la façon dont les méthodes peuvent être héritées. Ce qui fait une plus grande différence serait la POO basée sur le slot (comme Python) vs le message (comme Ruby), et si vous avez une liaison tardive ou précoce.
saolof