Quanto è sbagliato parlare di "metodi" C ++ (rispetto a "funzioni membro")?

Ho capito che secondo il C ++ specifica non esiste una cosa come un "metodo", e alcuni (molti? La maggior parte?) C ++ i programmatori considerano "metodo" per essere un Java-ismo. D'altra parte, anche su un forum C ++ le persone sembrano parlare di metodi senza contrazioni. Sto cercando convenzioni note o pratiche comuni riguardo a questa terminologia.

Sto documentando un'API che ha entrambe le versioni C ++ e Java. Gli sviluppatori hanno mantenuto i nomi di classe e metodo / membro-funzione uguali tra i due, presumibilmente per la convenienza nel porting e nel testing. Per questo motivo, parte di ciò che deve essere documentato su queste API è "al di sopra" della scelta della lingua; Devo poter parlare in generale di Foos and Bars, con i loro metodi baz () e mumble () ...?

Se parlo di metodi che i programmatori Java lo considereranno naturale e, a quanto pare, i programmatori C ++ probabilmente capiranno, ma alcuni lo considereranno errato. La mia domanda è: quanto è atroce in pratica ? Come si parla convenzionalmente delle funzioni dei membri del C ++ in contesti di "OOP generale", rispetto a quelli specifici del C ++? Esiste un modo migliore per parlare delle funzioni dei membri in un modo che non è errato per entrambe le lingue? ("Funzioni membro" è un po 'prolisso).

Questo non è un sondaggio d'opinione; Sto cercando di determinare se ci sono convenzioni effettive o pratiche comuni per affrontare questo problema.

Sono a conoscenza di questa domanda , ma riguarda OOP in generale e non chiedono lingue specifiche.

object-oriented c++ terminology

— Monica Cellio
fonte

Ho letto il centro assistenza ed esaminato l'elenco dei tag prima di chiederlo. Ho fatto qualcosa di sbagliato chiedendolo qui?

— Monica Cellio,

Il voto ravvicinato che hai è principalmente basato sull'opinione che potrebbe benissimo essere. Non sono sicuro di quanto possa funzionare bene su qualsiasi sito SE solo perché è difficile dire in modo autorevole se le persone saranno irritate o meno con te e con quale ampiezza be .. Una persona potrebbe pensare che vada benissimo e un'altra penserà che sia una terribile violazione della terminologia, proprio come hai descritto nel Q- per questo è relativamente un tipo di opinione solo di opinione

— Jimmy Hoffa,

Il concetto di metodi OOP sarebbe mappato in modo più pulito alla "funzione di membro virtuale" in C ++, ma è la stessa cosa. C'è una terminologia peggiore sul lato Java, come i "metodi statici" che non sono metodi ma funzioni. Continua a usare la parola "metodo" indipendente dalla lingua e tutti capiranno cosa intendi. Se qualcuno insiste sul fatto che il C ++ non ha metodi, questo è semplicemente errato e incredibilmente fastidioso spargimento di bici.

— amon,

@JimmyHoffa è meglio?

— Monica Cellio,

Basta chiamarli metodi nel tuo documento API multilingue. È possibile includere una frase nel testo introduttivo come "Per cercare di rimanere agnostici nel linguaggio di programmazione, questa documentazione dell'API utilizzerà il termine metodo per fare riferimento alle funzioni membro C ++".

— Brandin,

Risposte:

Perché non includere una spiegazione (proprio come nella domanda) nella parte introduttiva della documentazione, ad esempio una sezione Convenzioni ? Quindi potresti spiegare che il termine "metodo", come usato nella tua documentazione, è inteso nel senso generico del metodo (Java), funzione membro (C ++), ... poiché la documentazione si applica a tutte le implementazioni.

— sceaj
fonte

Questo è quello che ho fatto, e finora le persone sembrano essere d'accordo. Grazie per il suggerimento

— Monica Cellio,

Bene, non verrai giustiziato per questo.

La lamentela nel mondo C ++ non è di correttezza pedante: è di ambiguità. Ci sono così tanti diversi tipi di "metodi" là fuori nel deserto a seconda del dominio di cui stai parlando, che un gruppo di noi preferisce attenersi alla terminologia standard per evitare incomprensioni in seguito. Ciò significa, approssimativamente, "funzione statica / [non statica] [pura] virtuale / [non virtuale] / [libera]".

Se invece scrivi "metodo" nella tua documentazione, alcuni programmatori C ++ potrebbero lamentarsi del fatto che non è davvero chiaro di cosa stai parlando, o preoccuparti che se non hai familiarità con questa convenzione C ++, quali altri ti perdi?

Ma sono sicuro che ci sono milioni di programmatori professionisti C ++ che a loro volta non hanno idea che questa sia una cosa. È un grande vecchio mondo.

Non verrai giustiziato per questo.

— Corse di leggerezza con Monica
fonte

Eiffel li chiama Routine o Funzionalità , il C ++ li chiama Funzioni membro e (quasi) ogni altro linguaggio OO mai creato nell'intera storia dell'informatica, sia prima che dopo il C ++ li chiama Metodi , in modo che quest'ultimo termine sia generalmente compreso anche da Programmatori C ++ (ed Eiffel), a meno che non abbiano mai sentito parlare di Simula, Smalltalk, Self, Objective-C, Newspeak, Java, C #, VB.NET, PHP, Python, Ruby, ECMAScript / JavaScript, Scala, CoffeeScript, ...

— Jörg W Mittag
fonte

Tranne il punto è che spesso significano cose leggermente diverse in quei domini. Ecco perché l'OP sta chiedendo se è meglio attenersi alla terminologia specifica del dominio e perché la risposta corretta è "sì" ...

— Lightness Races with Monica

Ho appena realizzato che hai dimostrato il mio punto citando JavaScript, che non ha nemmeno classi (il suo OO è basato su prototipo). Quindi come possono i metodi JavaScript essere uguali ai metodi altrove? L'intelligibilità reciproca che stai sostenendo in realtà non esiste.

— Lightness Races con Monica

OOP basato sul prototipo non fa alcuna differenza. OOP si basa sul concetto che gli oggetti comunicano tramite messaggi (come i server che inviano richieste l'uno all'altro) e un metodo si riferisce al modo (metodo) in cui un determinato oggetto risponde a un determinato messaggio. Prototype OO fa la differenza solo riguardo al modo in cui i metodi possono essere ereditati. Ciò che fa una differenza più grande sarebbe OOP basato su slot (come Python) vs basato su messaggi (come Ruby), e se hai un'associazione tardiva o anticipata.

— saolof