5

Go method receivers take a type along with a variable name for the type, example:

type MyFloat float64

func (x MyFloat) Abs() float64 {
    if x < 0 {
        return float64(-x)
    }
    return float64(x)
}

func main() {
    f := MyFloat(-math.Sqrt2)
    fmt.Println(f.Abs())
}

The receiver takes "x" along with the type receiving the method. What is the significance of the name 'x'. Since i am able to invoke the method on any instance of MyFloat ( not just on the one named as x ) why do i have to specify the x ? Since the receiver is a Type or a reference to a type why not simply take the type or the pointer alone like this

func (MyFloat) Abs() float64 {
    if this < 0 {
        return float64(-this)
    }
    return float64(this)
}

My assumption is instead of this in Java golang allows any name? Is that so ?

Jonathan Hall
  • 75,165
  • 16
  • 143
  • 189
broun
  • 2,483
  • 5
  • 40
  • 55
  • Good question. It is beyond me, why the "convention over configuration" police aka the go language creators (see e.g. capitalization of variables etc. determining visibility) would make the name of `this` configurable. Can there ever be two receivers in a method or why would anyone need that? `this` is a convention anyone can get used to in no time. – Evgeniy Berezovsky Aug 29 '19 at 22:50

3 Answers3

3

Your assumption is exact: the receiver has to be explicitly named in a method definition. It avoids any ambiguity. In your example, how could the Go compiler guess that x is the receiver?

Note that using "self" or "this" or "me" as the receiver name is considered as bad style in go. The name should be short - one letter is fine. See more information at https://code.google.com/p/go-wiki/wiki/CodeReviewComments#Receiver_Names

Didier Spezia
  • 70,911
  • 12
  • 189
  • 154
  • 1
    It says "Don't use generic names such as "me", "this" or "self", identifiers typical of object-oriented languages that place more emphasis on methods as opposed to functions". A function bound to a receiver is a method. Is this a valid stmt, if so i dont entirely understand why using this or self would be bad since it would be emphasizing the fact that the method is acting on an instance of a type? – broun Aug 16 '14 at 21:16
1

It's a design choice.

Java use this, Go-lang choose another mechanic.

In Go, it's legal to make the receiver a pointer or not.

Let's see:

func (t Type)  Id()  { return t }
func (t *Type) IdPointer() { return t }

What if Go use Java's design?

It will became:

func (Type)  Id()  { return this }
func (*Type) IdPointer() { return this }

Firstly, it is confused that what (*Type) is.

Secondly, this can also be a pointer or a value. Also confused.

But, anyway, you can design Go-lang like this.

It is a choice after all.

XiaoChi
  • 369
  • 4
  • 4
0

I think you are not using correctly you should use it in a struct.Where the receiver makes a reference to the struct's fields.

For example:

package main
import "fmt"

type Decimal struct {
    first float64
}

func (x Decimal) out() float64 {
    return x.first
}
func main() {
    var start Decimal
    start.first = 10.8
    show := start.out()
    fmt.Println(show)
}
Mogsdad
  • 44,709
  • 21
  • 151
  • 275
harold ramos
  • 639
  • 7
  • 6