How to refactor out this function

[Tong Sun]

Hi, 

Consider this function:

	b.Handle("/hello", func(m *tb.Message) {
		b.Send(m.Sender, "hello world")
	})

I tried to refactor the above function to func sayHi(m *tb.Message) {...},  so that I can give an alias to the above /hello command (say to define a /hi command), but found that I cannot use bwithin it any more.

So, how to refactor out this function?

thx

[Sam Whited]

You'd want to use a function that returns another function and takes the dependencies as arguments, something like this:

func Sender(b *B) func(m *tb.Message) {
return func(m *tb.Message) {
b.Send(m.Sender, "hello world")
}
}

s := Sender(b)
b.Handle("/hello", s)
b.Handle("/hi", s)


—Sam

--
Sam Whited
s...@samwhited.com

[Tong Sun]

Thanks a lot Sam. 

A follow up question, what's the Go way of naming such functions?

Java would name it like "somethingFactory", C# would name it like "GetHelloFunction". 

what's the typical Go naming, for a factory function that generates Hello handling function? 

thx

[David Skinner]

I cannot speak for the community, only for myself.

I like to use NounVerb combinations that make sense with the package name.

    package.NounVerb()

    handles.HelloSend()

I can then define the interface as VerbEr

    type HelloSender interface {

        HelloSend()

    }

My son spent too many years using Java and tends to use Java style names, it is important that you maintain a consistent style with your programming team members. If you are not part of a team, you should join a team.

[Tong Sun]

Thanks a lot for the input. 

Out of curiosity, for those action based functions, how would you name them using NounVerb combinations? For example, 

SayHi(), or PlayCards(), etc. 

thx

[Jim Bishopp]

HelloSender can SendHello(). 

Sometimes I find better ways of naming things while adding comments, because the act of describing what something is and does surfaces name-smells. 

HelloSender can HelloSend(). wat? 

HelloSend is a polite thing to say when you finally meet Send.

io.RuneReader will ReadRune, not ask a Rune to Read. :)

[David Skinner]

I think you should listen to James. He is quite right.

Sometimes I am not thinking in English so a lot of people complain if I am the one who names things. And like James, I am always figuring out better ways to name things while making comments.

    RuneRead makes sense to me if I am thinking in Japanese. In English, well not so much. So I would write RuneRead but if I were working with James I would defer to his better judgement and use ReadRune.

Fortunately, refactoring in Go is extremely easy, even complex refactoring of interrelated packages using GoLand.

So that is my life, I give things bad names, then give them better names while polishing the comments, then refactor the names after a code review by another party. When finished it usually is easy to read and understand, you can read it out loud and it will make sense. Well sometimes.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/iAPWMNP5LSk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.