Naming convention for method receiver?

[Han-Wen Nienhuys]

Hi there,

I find myself wanting to use a standard name receivers in methods,
like 'self' in Python.

Is there an accepted standard for this? (I am inclined to go with
'me' as it is short yet readable.)

--
Han-Wen Nienhuys
Google Engineering Belo Horizonte
han...@google.com

[Gustavo Niemeyer]

Hi there,

> Is there an accepted standard for this?  (I am inclined to go with
> 'me' as it is short yet readable.)

Unlike Python, the receiver tends to get named according to the actual
type, and many times it's just the lowercased first letter of the type
name, like (decoder *Decoder) or (d *Decoder).

--
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/blog
http://niemeyer.net/twitter

[chris dollin]

On 28 December 2010 19:11, Han-Wen Nienhuys <han...@google.com> wrote:
> Hi there,
>
> I find myself wanting to use a standard name receivers in methods,
> like 'self' in Python.
>
> Is there an accepted standard for this?  (I am inclined to go with
> 'me' as it is short yet readable.)

I think part of the point of the method-declaration syntax of Go
is so that you can choose any name you like -- it doesn't need a
separate standard.

One naming convention I use is the first-letter-of-type rule:

func (f *File) whatever ...
func (s string) wossname ...

The second is the appropriate-direction rule:

func (to *File) thingy( from *File ) ...
func (from *Source) tritTrot( to *Sink ) ...

The third is the well-known-convention rule:

func (x Numeric) makePoint( y Numeric) ...

Pick the name that makes the same sense as it would if the
receiver were any old argument -- after all, it pretty much is.

Chris

--
Chris "allusive" Dollin

[pablo....@gmail.com]

Will I be frowned upon if I call the receiver "this"?

as in:

func (this *Foobar) foo() {

    this.bar()

[Dave Cheney]

Yes

> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[luz...@gmail.com]

On Tuesday, December 28, 2010 8:11:20 PM UTC+1, Han-Wen Nienhuys wrote:

Hi there,

I find myself wanting to use a standard name receivers in methods,
like 'self' in Python.

Is there an accepted standard for this?  (I am inclined to go with
'me' as it is short yet readable.)

Actually golint warns against 'me', 'self' and 'this': https://github.com/golang/lint/blob/master/lint.go#L775 

[Rick]

[Mateusz Czapliński]

It's worthy to note, that in case like:

    func (to *File) thingy(from *File)

should you need, you can then trivially change it to:

    func thingy(to, from *File)

often without touching a bit of the func body. And surprisingly to me, I find I'm doing it much more often than I would expect, and it thus makes refactoring feel lighter, which is a good thing.

/Mateusz.

[Rick]

Well I know Go is an opinionated language and all, but I think self immediately imparts more information about what is being referred to than a single-letter derived from the type. And since I'm opinionated too, I'll probably continue to use self ;-)

On Tuesday, 28 December 2010 19:11:20 UTC, Han-Wen Nienhuys wrote:

[Jan Mercl]

On Tue, Sep 3, 2013 at 11:02 AM, Rick
<thesuggested...@gmail.com> wrote:
> Well I know Go is an opinionated language and all, but I think self
> immediately imparts more information about what is being referred to than a
> single-letter derived from the type. And since I'm opinionated too, I'll
> probably continue to use self ;-)

Consider:

func (n *Node) Walk() {
for ; n != nil; n = n.Next() {
Whatever(n.Data)
}
}

It's clear that 'n' is not 'self'. It can be assigned to and it can
point to multiple different selves while the method is executing.
Kinda schizophrenic "self" then, right?

And what about

type Int int
func (i Int) foo() {}

? Is a number '3' self? I don't think so. 'self' or 'this' are naming
conventions applicable, if at all, to references. It sounds strange
elsewhere, IMHO.

Another consideration:

func (id T) name(arg U, arg2 V, ...)

is semantically equal to

func name(id T, arg U, arg2 V, ...)

So if someone argues that 'id' should be named 'self' or 'this' then,
to be consistent, such person should name every first parameter of any
function 'self' or 'this' as well. Then we would read in package
"fmt":

func Printf(self string, args ...interface{}) { ... }

In short, naming a parameter mechanically/monotonically is perhaps the
way a code generator can work. Humans are more creative for their own
good. Good naming pays back when the code is read.

-j

[Konstantin Khomoutov]

On Tue, 3 Sep 2013 01:56:50 -0700 (PDT)
Rick <thesuggested...@gmail.com> wrote:

> > I find myself wanting to use a standard name receivers in methods,
> > like 'self' in Python.
> >
> > Is there an accepted standard for this? (I am inclined to go with
> > 'me' as it is short yet readable.)

Just look at the code of the Go standard library -- you'll discover
that in most cases a short abbreviation of the receiver's type is used,
like

func (mr *MyReader)DoSomething {
mr.Read(...)
...
}

I find it a good idea because coupling of methods with their respective
types is more loose than in "true OOP" languages.

[Nigel Tao]

On Tue, Sep 3, 2013 at 7:02 PM, Rick
<thesuggested...@gmail.com> wrote:
> Well I know Go is an opinionated language and all, but I think self
> immediately imparts more information about what is being referred to than a
> single-letter derived from the type. And since I'm opinionated too, I'll
> probably continue to use self ;-)

You are of course free to use your own personal style on your own
code, but the Go team are strongly opinionated on style (e.g. gofmt)
because having a standard style means there is one less thing to think
about when reading or writing larger code bases; those with more than
one author. If you ever want your Go code to be used (or simply read)
by other Go programmers, then I would strongly recommend following the
standard style, which is to name receivers like any other argument and
not "self" or "this". Conversely, if you read or modify other Go
programmer's code, I think you'll get used to the style surprisingly
quickly, just like gofmt's style decisions.

[Rick]

I hesitate to prolong the religious discussion, but Jan's examples prompt a few observations.

Jan asks us to consider: 

        func (n *Node) Walk() { 
                for ; n != nil; n = n.Next() { 
                        Whatever(n.Data) 
               } 

        } 

I realize Go is only loosely object-oriented, but the principals of Object-oriented programming are possible to follow to some extent in any programming language. One of the OOP practices I value is that methods on an object (instance of a type in this case) should operate on the type (e.g., getArea(), setName(), getNext(), etc). In the example above, Walk() is more properly implemented as a function that takes a node as argument and Walks the path:

 func Walk(n *Node) { 

       for ; n != nil; n = n.Next() { 
              Whatever(n.Data) 

        } 
 } 

Methods should not be used simply as another way to pass an instance of the type as an argument to a function. This applies to Jan's later comment as well:

        func (id T) name(arg U, arg2 V, ...) 

        is semantically equal to 

        func name(id T, arg U, arg2 V, ...) 

I realize this is old-school OOP, but while these may be operationally equivalent they are not, in OOP, semantically equivalent.

Jan asks what about 

        type Int int 
        func (i Int) foo() {} 

Not sure what exactly foo() is doing, but using a slightly less contrived example, I see no problem with the following

        type Int int 
        func (self Int) lessThan(i Int) bool {

             return self < i

        } 

Concerning the argument that it requires less thinking to use a different receiver name for each Type. I can't see how you can have less thinking than simply using self or this as the receiver name. It makes the places in the method definition where the code is acting on the instance stand out. The type itself is named in the signature of every method declaration so it hardly need be repeated in the variable name. Such a practice, adopted widely, will make for more readible code with less mental effort.

Naming is clearly a matter of taste and I recognize using self/this is not the taste of the Go gang. Regardless of what naming convention is used for receivers however, I think it's important to following good object-oriented design when creating abstract data types in Go.

 

point to multiple different selves while the method is executing. 
Kinda schizophrenic "self" then, right? 

And what about 

        type Int int 
        func (i Int) foo() {} 

? Is a number '3' self? I don't think so. 'self' or 'this' are naming 
conventions applicable, if at all, to references. It sounds strange 
elsewhere, IMHO. 

Another consideration: 

        func (id T) name(arg U, arg2 V, ...) 

is semantically equal to 

        func name(id T, arg U, arg2 V, ...) 

So if someone argues that 'id' should be named 'self' or 'this' then, 
to be consistent, such person should name every first parameter of any 
function 'self' or 'this' as well. Then we would read in package 
"fmt": 

        func Printf(self string, args ...interface{}) { ... } 

In short, naming a parameter mechanically/monotonically is perhaps the 
way a code generator can work. Humans are more creative for their own 
good. Good naming pays back when the code is read. 

-j 

Konstantin Khomoutov

Sep 3

Re: [go-nuts] Re: Naming convention for method receiver?

On Tue, 3 Sep 2013 01:56:50 -0700 (PDT) 
Rick <thesuggested...@gmail.com> wrote: 

> > I find myself wanting to use a standard name receivers in methods, 
> > like 'self' in Python. 
> > 
> > Is there an accepted standard for this?  (I am inclined to go with 
> > 'me' as it is short yet readable.) 

Just look at the code of the Go standard library -- you'll discover 
that in most cases a short abbreviation of the receiver's type is used, 
like 

func (mr *MyReader)DoSomething { 
  mr.Read(...) 
  ... 
} 

I find it a good idea because coupling of methods with their respective 
types is more loose than in "true OOP" languages. 

Nigel Tao

01:07 (9 hours ago)

[Aram Hăvărneanu]

Go code doesn't use methods to satisfy some OOP mantra, it has methods to satisfy interfaces or bring them to life.

--
Aram Hăvărneanu

[Rick]

Sure. But following object-oriented principals is good practice in that context, not merely a "mantra."

[Konstantin Khomoutov]

On Wed, 4 Sep 2013 06:21:46 -0700 (PDT)
Rick <thesuggested...@gmail.com> wrote:

> Sure. But following object-oriented principals is good practice in
> that context, not merely a "mantra."

We've been brainwashed with OOP for so long that it doesn't hurt to
take a bit overly critical stance with relation to it in the context of
Go ;-)

[Stefano Casillo]

On Tuesday, 3 September 2013 04:12:22 UTC+2, Dave Cheney wrote:

Yes

On Tue, Sep 3, 2013 at 10:49 AM,  <pablo....@gmail.com> wrote:
>
> Will I be frowned upon if I call the receiver "this"?

ouch.. time to get rid of my "this" almost everywhere

 

[Rick]

Brain-washed is a bit strong. I'd agree that our thinking has been overly influenced by a particular incarnation of OO (Java) for some years. And I wouldn't be on this list if I didn't find Go a breath of fresh air. But I disagree there is a need to be overly critical of OOP principals. There is only a need to understand them and use them (or not use them) wisely in the context of this great new language. Simply saying "this/self is bad" is a bit much.

[Henrik Johansson]

Many OO practices have a sound basis. Dissing them all because they are OOP is not rational.

It is as if the pure functional styles only idea is to use "each" (or what have you flatmap etc...) to save keystrokes which of course is not where the bang is. 

Still I have adopted this pasrticular style it seems, I had to check some code and now I apparently type:

func (n *Node) Next().....

without even thinking about it.

It is not really a biggie. 

--

[Kyle Lemons]

On Wed, Sep 4, 2013 at 4:51 AM, Rick <thesuggested...@gmail.com> wrote:

I hesitate to prolong the religious discussion, but Jan's examples prompt a few observations.

Jan asks us to consider: 

        func (n *Node) Walk() { 
                for ; n != nil; n = n.Next() { 
                        Whatever(n.Data) 
               } 

        } 

I realize Go is only loosely object-oriented, but the principals of Object-oriented programming are possible to follow to some extent in any programming language. One of the OOP practices I value is that methods on an object (instance of a type in this case) should operate on the type (e.g., getArea(), setName(), getNext(), etc). In the example above, Walk() is more properly implemented as a function that takes a node as argument and Walks the path:

 func Walk(n *Node) { 

       for ; n != nil; n = n.Next() { 
              Whatever(n.Data) 

        } 
 } 

I disagree.  This now makes it impossible for me to make a

type Walker interface {

  Walk()

}

and use that to walk the various structures I may have in my program.  In Go, methods are not about satisfying some semantic relation, it's about making code that makes sense--tying behavior to data, and generalizing or utilizing behaviors by making interfaces where they apply more broadly.

 

[Nigel Tao]

On Wed, Sep 4, 2013 at 9:51 PM, Rick
<thesuggested...@gmail.com> wrote:
> Concerning the argument that it requires less thinking to use a different receiver name for each Type. I can't see how you can have less thinking than simply using self or this as the receiver name.

You misunderstand my argument. It's not that calling the receiver "n"
instead of "this" requires less thinking per se. It's that it requires
more thinking if I use (and read) package github.com/foo/x that calls
its receivers "n", and I also use (and read) package
code.google.com/p/bar/y that calls its receivers "this".

This discussion has put forward valid arguments for "n" style and for
"this" style. The bigger point is that the Go community has chosen
*one* style, and that one is "n", and that it's "has chosen" instead
of "is choosing".

An analogy is the eternal tabs versus spaces debate. There are valid
arguments for tabs, and valid arguments for spaces. Personally, I was
a spaces guy, but in Go, I am happy to lose the argument in order to
*end* the argument. It is something I no longer think about; I just
apply gofmt and move on. If gofmt could also pick my receiver names
then I would accept that too, but that problem is not as easily
automatable as indentation.

In comparison, I still sometimes work on C/C++ code, and dig into
third party libraries. libpng has its own self-consistent indentation,
brace, naming and commenting style. libjpeg also has its own
self-consistent style. freetype has its own self-consistent style. But
they are *different styles*, and when doing work that touches code
*written by multiple authors in multiple styles*, the context
switching is a cost.

You may not appreciate that cost, if you only work with code that you
have written yourself. But the stylistic decisions that the Go team
has made was based on our experience working on large codebases. I
repeat that if you ever want your Go code to be used (or simply read)

by other Go programmers, then I would strongly recommend following the

standard style.

[bjr...@gmail.com]

Alternate discussion: https://plus.google.com/106530954599911462020/posts/4xtRBmHGWgf