GO - How to define methods of named type?

Question

In GO, rule is, methods can be defined only on named type and pointer to named type.

---

In C, below code, operations are defined on type(say List),

typedef struct List List; //list.h
typedef struct {

         bool(*canHandle)(ImplType);
        List*(*createList)();
        ....  
        const void*(*listGetItem)(List*, const int);
         .....
         void(*swap)(List*, int, int);
}ListHandler;


typedef struct{

  ListHandler *handler;
}ListRtti;


typedef struct List{

  ListRtti rtti; // operation on type List
  const void **array;
  /* For housekeeping - Array enhancement/shrink */
  int lastItemPosition;
  int size;
}List;

---

In Java, operations are defined on type(say DList),

public class DList {
  private DListNode sentinel;
  private int size;
  public void addItem(Object item){
    ...
  }
  ....
}

---

But in GO, code below, operations are allowed on named type and pointer to named type.

package main

type Cat struct {
}

func (c Cat) foo() {
   // do stuff_
}

func (c *Cat) foo() {
  // do stuff_
}

func main() {

}

---

Question:

1)

What is the idea of defining a method on a pointer to named type?

2)

How can a programmer know before hand, if foo() has to work as pass by value/reference? Why GO compiler restrict defining method on both named typed and pointer to named type?

Answer 1

Most OOP languages pass the current object (“invocant”) as a pointer or equivalent kind of reference. In Java and C++ the invocant is called this, in Python it's an explicit argument called self. In Java and Python this is zero-cost because their objects already are reference types. In C++, using a pointer (or reference) is necessary because that language has value semantics. If this were a value instead of a reference, the class defining the method could not be subclassed.

Like C++, Go has value types but it doesn't really have inheritance and can't override methods, so using a pointer is not necessary.

However, using a pointer is useful when:

• you want to modify the invocant, e.g. assign to a field of a struct.

• the type is large so a copy would be more expensive than using a pointer.

Conversely, using a non-pointer type for the invocant is useful if that type is very small and if you don't want to modify that object. In general, you'd use a non-pointer invocant for “primitive” types since they are fairly small. This should be treated as a micro-optimization; in most cases you do want a pointer for user-defined types.