Go Methods
External
Internal
Overview
Go allows associating arbitrary behavior with built-in or custom types, which contributes to the object-oriented character of the language. Note that Go is not a fully object-oriented language, it misses type inheritance, for example.
Syntactically, the association of the behavior with the type is done by declaring a function that encapsulates the behavior we want to add to the type, and adding a receiver to its signature:
func (r ReceiverType) FunctionName(parameters, ...) (return_declaration) {
...
}
If the name of the method starts with an uppercase letter, the method is automatically exported by the package. As result of this association, the function becomes a method of the type and a member of the method set of that type.
The declaration is identical to that of a regular function, with the exception of the receiver parameter, which precedes the function name. The receiver parameter gives the method's body access to the instance of the associated type. Aside from its special syntactical position, all other aspects the receiver parameter is identical with the regular parameters of the function.
An aspect that has profound implications on the relationship between the method and the type instance is whether the receiver parameter is a value or a pointer. The deciding factor should be whether the method is intended to change the state of the receiver. Use pointer receivers if you intend to let the method modify the state of the receiver instance. See Deciding between Value or Pointer Receiver.
When naming a method, consider if the name clashes with well-known methods names. See Method Naming for more details.
Receiver
The receiver is the instance to invoke the method on. It is passed to the method as an implicit parameter, which does not differ in any way from the "regular" parameters. We call it the receiver parameter. Loosely, it is the logical equivalent of the self function parameter in Python and the implicit method parameter this in Java. The receiver parameter can be simply thought of as the first parameter of the function. In the underlying implementation, it is indeed not much else indeed.
As with the regular parameters, the receiver parameter can be a value or a pointer, and it is called a value receiver or a pointer receiver, respectively.
Value Receiver
func (r ReceiverType) MethodName(parameters, ...) (return_declaration) {
...
}
A value receiver gives access to the copy of the value the method is invoked on, inside the method. As such, the original value outside the method cannot be modified by the method.
The method is invoked with the usual dot notation syntax:
func (r SomeType) SomeMethod() {
...
}
s := SomeType{}
s.SomeMethod()
Pointer Receiver
func (r *ReceiverType) MethodName(parameters, ...) (return_declaration) {
...
}
A pointer receiver gives access to the variable the method is invoked on, inside the method. As such, the method may modify the state of the original variable.
Deciding between Value or Pointer Receiver
The deciding factor should be whether the method intends to change the state of the receiver.
If the method is intended to modify the state of the receiver instance, use a pointer receiver. Use a value receiver otherwise. Since in this case the receiver argument is passed by value, the method will not be able to modify the original receiver, intendedly or erroneously.
Go documentation (Link?) recommends to not mix value and pointer receivers when defining methods for a type.
Receiver Parameter Naming
As we write idiomatic Go code, it is common to use the first letter or a short two-letter abbreviation of the type as the name of the receiver parameter. A short name makes sense because these parameters typically appear on almost every line of the method body. Receiver names should be consistent cross a type's methods, do not use one name in one and other name in another.
func (b *Buffer) Read(p []byte) (n int, err error)
func (sh serverHandler) ServeHTTP(rw ResponseWriter, req *Request)
In our case, if the name of the type is Color, the name of the parameter is c or even color. We might even consider naming the receiver parameters with abbreviations of the interfaces they represent. See this article for arguments against naming that parameter "this" or "self".
Alos see:
Method Set
A method set of a non-interface type determines the methods that can be called on the instances of that type. The method set of the non-interface type T is formally defined as the set of all methods declared with a receiver type T. Every type has a possibly empty method set associated with it.
The method set of the pointer to a non-interface type is different from the method set of the type. The method set of a pointer to a type T is formally defined as the set of all method declared with a receiver *T and T. The method set of the pointer to the type T includes the method set of the type T. This is because given a pointer, we can always obtain the value, while vice-versa is not always true. This is a code example that makes this point:
The method set of an interface type is the intersection of the method set of each type in the interface's type set. The resulting method set is usually just the set of declared methods in the interface.
In a method set, each method must have a unique, non-blank method name.
Method Naming
There is a number of well-known methods names like Read, Write, Close, Flush, String, etc. that have canonical signatures and meanings. To avoid confusion, do not give your methods one of these names, unless it has the same signature and meaning. If indeed the method you are developing has the same meaning as a method on a well-known type, give it the same name and signature: your string converter method should be called String, not ToString.
TODO
Continue and deplete Go_Language_Object_Oriented_Programming#Methods.