26

I understand that according to the C++ spec there is no such thing as a "method", and some (many? most?) C++ programmers consider "method" to be a Java-ism. On the other hand, even on a C++ forum people seem to talk about methods without twitching. I am looking for known conventions or common practices regarding this terminology.

I am documenting an API that has both C++ and Java versions. The developers actually kept the class and method/member-function names the same between the two, presumably for expedience in porting and testing. Because of this, some of what needs to be documented about these APIs sits "above" the choice of language; I need to be able to talk in general about Foos and Bars, with their baz() and mumble()...methods?

If I talk about methods Java programmers will consider it natural and, it appears, C++ programmers will probably understand but some will consider it to be incorrect. My question is: how heinous is this in practice? How are C++ member functions conventionally talked about in "general OOP" contexts, as opposed to C++-specific ones? Is there a better way to talk about member functions in a way that's not incorrect for either language? ("Member functions" is a little verbose.)

This isn't an opinion survey; I'm trying to determine if there are actual conventions or common practices to address this problem.

I am aware of this question, but it's about OOP in general and doesn't ask about specific languages.

Community
  • 1
Monica Cellio
  • 1,327
  • 2
  • 11
  • 17
  • I did read the help center and review the tags list before asking this. Did I do something wrong by asking this here? – Monica Cellio Dec 30 '15 at 21:11
  • The close vote you have is for primarily opinion based which this may well be.. Not certain how well this can work on any SE site just because it's hard to authoritatively say whether or not people will be irritated at you and to what amplitude they will be.. One person may think it's totally fine and another will think it's a terrible breach of terminology, just as you described in the Q- because of this it's relatively an opinion-only kind of thing – Jimmy Hoffa Dec 30 '15 at 21:20
  • @JimmyHoffa thanks. I anticipated POB and was trying to fend that off; I'm not interested in people's *personal opinions*, but want to know what is *actually done* or if there are *conventions* for this. How can I make that clearer? (BTW, I can't see close votes on this site; the first response to the question was a downvote sans comment, which is why I made my comment.) – Monica Cellio Dec 30 '15 at 21:21
  • 2
    The OOP concept of methods would map most cleanly to “virtual member function” in C++, but its the same thing. There's worse terminology on the Java side, such as “static methods” which aren't methods but functions. Just keep using the language-independent word “method”, and everyone will understand what you mean. If someone insists that C++ doesn't have methods, that's just factually wrong and incredibly annoying bike shedding. – amon Dec 30 '15 at 21:24
  • @amon: I like how the first half of your comment explains (correctly) that the term "method" is hopelessly ambiguous and unclear, then the second half of your answer viciously berates anyone who doesn't think "everyone will understand what you mean". That's great work! – Lightness Races in Orbit Dec 30 '15 at 21:27
  • @amon to be sure, I always like the term "member" for cross-language referencing specifically that it's a member of an instance; so "member" function would be my fallback and I could be wrong but I think Java people would absolutely recognize what it meant. – Jimmy Hoffa Dec 30 '15 at 21:27
  • For reference, there was a 47,329-hour conversation in the Whiteboard chatroom yesterday that stemmed from Python's notion of "method" apparently differing almost completely from that which you deem "language-independent" and unambiguous. – Lightness Races in Orbit Dec 30 '15 at 21:28
  • @MonicaCellio if you want this to be less opiniony - you should mention in the Q you want any known conventions or common practices regarding terms for this. – Jimmy Hoffa Dec 30 '15 at 21:30
  • 1
    @JimmyHoffa is this better? – Monica Cellio Dec 30 '15 at 21:32
  • 3
    Just call them methods in your cross-language API doc. You could include a phrase in the intro text like "To try to remain programming language agnostic this API documentation will use the term method to refer to C++ member functions." – Brandin Dec 31 '15 at 06:50
  • @LightnessRacesinOrbit, you began with "For reference", and intrigued me, but didn't actually provide a reference (e.g. link to the discussion or a summary). In what way is the "method" term treated differently in Python? – yoniLavi Jan 06 '16 at 23:40
  • @yoniLavi: Oh it has "class methods" and "instance methods" and "static methods" and I don't remember which is which but one of them bears no resemblance whatsoever to what one may deem to be a "method" in many other popular languages with OO support. You're free to look up the discussion in the transcript. – Lightness Races in Orbit Jan 06 '16 at 23:42
  • It may be a little late to say that but here I go: in C++, you technically must say "member function", but here is what you can read in the C++ Programming Language - 4th edition (Bjarne Stroustrup), Chapter 20, Section 3.2, page 586 : "A virtual member function is sometimes called a method". – Senua Jan 03 '22 at 08:06

3 Answers3

20

Well, you're not going to get executed for it.

The complaint in the C++ world is not one of pedantic correctness: it's one of ambiguity. There are so many different kinds of "methods" out there in the wilderness depending on what domain you're talking about, that a bunch of us prefer to stick to standard terminology to avoid misunderstandings later. That means, roughly, "static/[non-static] [pure] virtual/[non-virtual] member/[free] function".

If you write "method" in your documentation instead, some C++ programmers may complain that it's not really clear what you're talking about, or worry that if you're not familiar with this C++ convention, what others are you missing?

But I'm sure there are millions of professional C++ programmers who themselves have no idea that this is even a thing. It's a big ol' world.

You're not going to get executed for it.

Community
  • 1
Lightness Races in Orbit
  • 8,755
  • 3
  • 41
  • 45
12

Why don't you include an explanation (very much like you did in your question) in the introductory part of the documentation, e.g. a Conventions section? Then you could explain that the term "method", as used in your documentation, is meant in the generic sense of method (Java), member function (C++), ... since the documentation applies to all implementations.

sceaj
  • 286
  • 1
  • 4
4

Eiffel calls them Routines or Features, C++ calls them Member Functions, and (almost) every single other OO language ever created in the entire history of computing, both before and after C++ calls them Methods, so that latter term should generally be understood even by C++ (and Eiffel) programmers, unless they really have never heard of Simula, Smalltalk, Self, Objective-C, Newspeak, Java, C#, VB.NET, PHP, Python, Ruby, ECMAScript/JavaScript, Scala, CoffeeScript, …

Jörg W Mittag
  • 101,921
  • 24
  • 218
  • 318
  • 1
    Except the point is that they often mean subtly different things across those domains. That's why the OP's asking whether it's better to stick to domain-specific terminology, and why the correct answer is "yes"... – Lightness Races in Orbit Dec 30 '15 at 23:39
  • Just realised you proved my point by citing JavaScript, which doesn't even have classes (its OO is prototype-based). So how then can JavaScript methods be the same as methods elsewhere? The mutual intelligibility you're claiming doesn't actually exist. – Lightness Races in Orbit Jan 06 '16 at 23:45
  • Prototype based OOP makes no difference. OOP is based on the notion that objects communicate via messages (like servers sending requests to each other), and a method refers to the way (method) in which any particular object responds to a given message. Prototype OO only makes a difference with regards to how methods may be inherited. What does make a bigger difference would be slot-based (like Python) vs message based (like Ruby) OOP, and whether you have late or early binding. – saolof May 27 '18 at 18:05