18

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.

  • 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
  • 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
  • 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 6:50
10

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.

  • This is what I did, and so far people seem to be ok with it. Thanks for the suggestion. – Monica Cellio Mar 20 '16 at 20:16
16

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.

3

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, …

  • 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 6 '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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.