Talk:Method (computer programming)
In use, a method is a function.. Fundamentally, Methods + Data = Object.. Just the elaborations of this invariant property of objects has muddied the definition of what an object is.. For instance inheritance is more a language construct than a property of an object.. Also a "Class" is the beginning state of an object, so what use is a class aside from an object, as objects could be used to make more objects.. I think over the years Java and C++ has muddied the definition of what an object is, when really its a simple concept that I believe (in conspiracy theory) that capitalists not interested in the adoption of object oriented languages has intentionally sabotaged to avoid the competition from perpetually consistent pluggable entities. Agents are merely mobile objects and whatever happened to the use of Agents? I challenge you to track down the use of Agents, popular in the 90s but was this just a fad? You may find they were systematically extinguished (I was told one such language that used agents as objects was forced out indirectly by Microsoft, but this is a rumor). --Rofthorax 10:38, 24 August 2005 (UTC)
Is static really the same as "shared"--I thought it was the opposite--static *fields* cannot be modified.
more information and more accurate information needs to be put here. I don't know enough about Java to help.
My references: (by memory)
Java Methods, avaliable directly from www.skylit.com
The static keyword is, by default, related to single storage. For instance, any modification of a static field will be seen by all instances of a given class as they are applied to the same piece of memory. There are exceptions, however. I will care to provide one example: global variables in C which are also static will have internal linkage, that is, they will only be seen by functions inside the same file (if, naturally, placed after the variable in question was defined).
The keyword global is related to access. A global variable is one which will be accessed by all functions which do not include definition of a variable of the same name and type. Global variables will naturally have a single piece of memory related to them. This means they are "static" in such sense. But a language may allow them to be defined as static and this will have a different behavior, as stated on the above paragraph.184.108.40.206 18:49, 18 January 2007 (UTC)
I would not consider static functions as methods [they're just functions associated with the class]. Similarly, constructors and destructors (in C++) are not strictly speaking methods. A method should be able to assume that invariants are satisfied on entry to the method, and should leave the object in a valid state. [unsigned]
Subroutines and Methods
- A subroutine is one possible way to implement a method. Wouter Lievens 14:33, 26 January 2007 (UTC)
"Method" is just a new word for function or procedure that has become popular in the object oriented paradigm. This article should refer to existing articles on functions and procedures, should relate methods to functions and procedures, and should explain in very clear terms that a method is simply a module of code that contains a sequence of instructions. Some methods attach to classes, others to objects, others to neither (in structured programming languages). There should be some explanation of parameters and return values, but nothing that duplicates discussions already in place under "function" or "procedure" or the more generic "subroutine".
Actually it's wrong to say that "method is just a new word for function or procedure." When I invoke a procedure, I can be sure exactly what code will be called. When I invoke a method of an object, the actual code will vary according to the class of the object (which might be different from what I expect.) (Erik Zoltan (talk) 16:33, 16 September 2008 (UTC))
It's true that a method invocation might execute one out of several polymorphic pieces of code. I would happily describe each polymorphic variation as a "method" - that is, a function or procedure. Are you implying that the word "method" applies only to the polymorphic signature, and a different word should be used to describe each of the implementations? If so, what word? Paul Foxworthy (talk) 04:08, 17 September 2008 (UTC)
Note that there already exists a definition on page Dynamic_dispatch;
dynamic dispatch is the process of mapping a message to a specific sequence of code (method) at runtime..
Disregarding the particular focus on dynamic dispatch leave us with the definition "dispatch is the process of mapping a message to a specific sequence of code (method)". This implies that the it is the message which is sent, delivered and understood (reacted to). That is, the polymorphic signature, including intended semantics, are captured within the message definition. It is important to clearly distinguish this from the method which contains the implementation details regarding what specifically should happen upon message delivery, with relation to specific object or class (or set of classes in the case of multi-methods). The two concepts are often confused, as well as the difference between methods and procedures as clarified by Erik Zoltan above.
Based on current terminology, I'd offer the general definition that a method is a self contained, specific sequence of code (e.g. a procedure or subroutine) that has been explicitly associated with an object or class and will be automatically selected for use upon delivery of the message it implements. This rules out general procedures, functions, lambdas, case blocks within switch statements (and by extension if-blocks) as well as blocks within for and while loops, which are generally not considered methods (except perhaps just before being extracted into such during refactoring), and rules in Erlang's message handling mechanisms. --Mike Amy 11 Oct 2009
I think that Mike Amy offers a correct definition and explanation above. However for a general audience it is desirable to define method without requiring the use of message which is often misunderstood. I would therefore tweak Mike's definition and say that a method is a subroutine or function explicitly associated with an object or class and leave it at that. Then I could define message, polymorphism and other higher-level concepts by referring to the method without circularity. --Erik Zoltan (talk) 02:04, 28 February 2010 (UTC)
The page as it exists today is unsatisfactory in at least the following respects:
- No mention of dynamic dispatch (thus, article is incomplete)
- No mention of late binding (thus, article is incomplete)
- No mention of polymorphism (thus, article is incomplete)
- Defines methods as "attached" to objects: see CLOS (thus, article is incorrect)
It does not fit in the hierarchy. Java's design is simply silly. This is because Java was designed to be unimplementable, dealing only with objects living... No beginning of the execution was designed. So main() was fit something like randomly. Please stop using java, consider ANY OTHER serious language. DrW —Preceding unsigned comment added by 220.127.116.11 (talk) 20:51, 22 April 2008 (UTC)
Java designed to be "unimplementable"? That must be why it's "unimplemented" to the point of market dominance. Truth is, Java's implementation of
main() is no more random than in C++. In neither language does the main routine fit into the class hierarchy. Both languages hack the OO paradigm in order to give programs a point of entry. I agree with anyone who wants to argue that C++'s enforcement of only one point of entry is cleaner, but to call Java's design "silly" is putting it way too strongly. --Rtperson (talk) 16:55, 10 September 2008 (UTC)
Simon says, "It's static. Show some respect."
I came here for an explanation of the "static" condition and I still don't get what it is, or why it matters, or - and this may be the more acute complaint - why it still matters. I never studied computer science but I program in Java every day and when the compiler jibs at my calling something static from a non-static something, I merely change this or that and the quibble is no more. Why? Why did I have to limbo under a five-foot bar, or jump over a five-inch one? Is there something about silicon, its chemistry or electronic properties, that forces, tortuously but inevitably, critical and profound decisionmaking about when stuff happens? Or is there something about memory management, some "best practice," that encourages if not requires some consideration of this? Or is this a relict of 1940's-vintage theoretical computer science, something that visionaries imagined could be a big deal, only once people managed to build the darn things, it turned out not to matter? But the neurosis (I think it's that, and in the case of Java know it's that) persists by sheer force of tradition?
Many, perhaps most other programming languages make no provision for this. They seem to work fine. I generously suppose the programmer who uses them gets comfortable in a fool's paradise, thus exposing himself to misadventures, disasters the Java compiler would pre-emptively have saved him from. But which disasters? Jahutter (talk) 23:01, 2 August 2012 (UTC)
- I'm rather surprised that someone can "program in Java every day" and not know what Static variables and methods are but in Java they apply to all the objects of a class rather than one or more instances of the class. So for example if you have an online store with Products you might have a static variable called numberOfProducts that kept track of the total number of instances of the class and you might have a static method called computeAverageCost that computed the average cost of all the products. As for other languages, it all depends. Essentially a static method or variable is more or less like a global variable of function in Lisp or other non OO languages. Or in some OO languages you have a meta object protocol where you can also do what static vars and methods do plus you can do a lot more such as dynamically redefining the class hierarchy at run time. --MadScientistX11 (talk) 14:52, 15 December 2014 (UTC)
- Here is a good tutorial that explains static methods and variables in Java: https://docs.oracle.com/javase/tutorial/java/javaOO/classvars.html --MadScientistX11 (talk) 15:51, 15 December 2014 (UTC)
Use of Main is terrible for a first example
Starting with the first example for a method with something defined on "Main" is an awful example. If you are going to define a method for a rectangle it should be defined on a rectangle object not on Main. The first example really misses the entire point of what OO and methods are supposed to be about. It's more the kind of example I would expect from a conventional programmer who doesn't really understand what methods and OO really are yet. MadScientistX11 (talk) 18:55, 17 December 2013 (UTC)
- I notice the "Main" and rectangle examples are continued in the rest of the article. Oy Vey! I don't like to remove large sections of an article without having something to put in it's place but I'm tempted (but won't for now) to just blank all that stuff. It really gives the wrong idea to anyone coming to this article for an overview of what a method is. "first do no harm" should be the rule I would think, better to say nothing than to give someone a wrong idea and the way methods are defined in this article as it currently stands looks like the examples were developed by someone who doesn't really know how to do OO at all. MadScientistX11 (talk) 15:10, 19 December 2013 (UTC)
- I just came back to this article. I took a closer look at the Example section. I'm going to delete it unless someone objects. For one thing, I don't think those kind of code examples belong in Wikipedia anyway. But in this case everything in that section is terrible as an example of a method anyway. Those examples don't communicate what differentiates a method from a procedure or function call. --MadScientistX11 (talk) 00:09, 8 December 2014 (UTC)
Removing Reference five on Virtual methods.
Currently the Virtual Methods section has the following for a reference:
Alexis Angelidis. "What is a virtual method?". http://www.cs.otago.ac.nz/postgrads/alexis/tutorial/: Online C++ FAQ/Tutorial and Advanced Questions. Retrieved 2011-08-12. "A virtual method in a parent allows children to have a different implementation for it. A pure virtual method in a parent forces children to have an implementation for it (interface in Java). A class with a pure virtual method is called virtual."
The actual text at this URL is just a page in a really bare bones tutorial that says:
"What is a virtual method? A virtual method in a parent allows children to have a different implementation for it. A pure virtual method in a parent forces children to have an implementation for it (interface in Java). A class with a pure virtual method is called virtual. "
I don't consider this an acceptable reference for this article. There are countless excellent books on C++ and Java or on OO in general that could be used as a reference. I'm in the process of getting some of those so will add better refs later but for now I'm just going to delete this reference. --MadScientistX11 (talk) 22:01, 10 December 2014 (UTC)
Should we create a new article: Method (C++)?
As I look at this article, a lot of it is C++ specific. It's written as if terms like member functions and virtual methods are widely used in most OO languages when these and other concepts here are specific to C++. I'm wondering if it would make sense to take much of the current article and create a new article that would be called Method(C++) and then leave the stuff that is generic to all OO in this article? I'm still thinking about how to structure it and what might go where but just thought I would throw out the idea and see if anyone else has opinions either way. --MadScientistX11 (talk) 22:14, 10 December 2014 (UTC)
- I thought about this a bit more and I think I'm going to not create a separate article. My preference is not to create new articles unless there is clearly a strong demand for it. As I thought about the logical conclusion of creating a new article for methods in C++ it seems to me the conclusion would be we have a separate article for Python, Java, Smalltalk, etc. They all have their own quirks in how they handle methods. And I think that would be ridiculous. So what I plan to do now is to edit the existing article to take out the C++ orientation from the general article and then create a new section within the article for methods in C++ and move the content I was thinking of spinning out into a new article into that section. I'm not going to document every time I make that kind of change from now on. For example: "member function" is not a term I've heard used outside of C++ so I'm removing it from the intro and will add it back to the C++ section. --MadScientistX11 (talk) 14:41, 11 December 2014 (UTC)