Mixing
What's the reason for having methods outside the definition of the struct?
Why do we have the methods declared outside the type definition of the struct? E.g.:
type antenna struct {
name string
length float32
girth float32
bloodtype string
}
func (p *antenna) extend() {
p.length += 10
}
It seems to me that the method could be part of the struct? (Let's ignore for now that structs are supposed to be value types)
type antenna struct {
name string
length float32
girth float32
bloodtype string
func extend() {
length += 10
}
}
This would be more similar to traditional OOP. I didn't find any good explanations of why it is done the way it is besides "structs are value-types and classes are reference-types". I know the difference, but it's not a satisfactory answer to me. In any way the method has to be called like this:
var x = antenna()
x.extend()
So what's the point of separating the the struct and methods? Having them visually grouped together in the code - as in typical OOP languages - seems useful to me?
go methods struct
asked Nov 20 '18 at 6:18
MuppetMuppet
1,96531627
add a comment |
Why do we have the methods declared outside the type definition of the struct? E.g.:
type antenna struct {
name string
length float32
girth float32
bloodtype string
}
func (p *antenna) extend() {
p.length += 10
}
It seems to me that the method could be part of the struct? (Let's ignore for now that structs are supposed to be value types)
type antenna struct {
name string
length float32
girth float32
bloodtype string
func extend() {
length += 10
}
}
This would be more similar to traditional OOP. I didn't find any good explanations of why it is done the way it is besides "structs are value-types and classes are reference-types". I know the difference, but it's not a satisfactory answer to me. In any way the method has to be called like this:
var x = antenna()
x.extend()
So what's the point of separating the the struct and methods? Having them visually grouped together in the code - as in typical OOP languages - seems useful to me?
go methods struct
asked Nov 20 '18 at 6:18
MuppetMuppet
1,96531627
3
You can't just ignore the difference between value and pointer receivers. This is important. Not all methods mutate the receiver. See time.Time for a prolific example. It's also very useful to be able put types and methods in separate files. This enabled easy code generation and architecture specific implementations.
– Peter
Nov 20 '18 at 6:42
5
Any named type can have methods, not just struct types.
– ThunderCat
Nov 20 '18 at 6:54
"This would be more similar to traditional OOP" -- So what? Go isn't OOP.
– Flimzy
Nov 20 '18 at 7:49
add a comment |
Why do we have the methods declared outside the type definition of the struct? E.g.:
type antenna struct {
name string
length float32
girth float32
bloodtype string
}
func (p *antenna) extend() {
p.length += 10
}
It seems to me that the method could be part of the struct? (Let's ignore for now that structs are supposed to be value types)
type antenna struct {
name string
length float32
girth float32
bloodtype string
func extend() {
length += 10
}
}
This would be more similar to traditional OOP. I didn't find any good explanations of why it is done the way it is besides "structs are value-types and classes are reference-types". I know the difference, but it's not a satisfactory answer to me. In any way the method has to be called like this:
var x = antenna()
x.extend()
So what's the point of separating the the struct and methods? Having them visually grouped together in the code - as in typical OOP languages - seems useful to me?
go methods struct
asked Nov 20 '18 at 6:18
MuppetMuppet
1,96531627
Why do we have the methods declared outside the type definition of the struct? E.g.:
type antenna struct {
name string
length float32
girth float32
bloodtype string
}
func (p *antenna) extend() {
p.length += 10
}
It seems to me that the method could be part of the struct? (Let's ignore for now that structs are supposed to be value types)
type antenna struct {
name string
length float32
girth float32
bloodtype string
func extend() {
length += 10
}
}
This would be more similar to traditional OOP. I didn't find any good explanations of why it is done the way it is besides "structs are value-types and classes are reference-types". I know the difference, but it's not a satisfactory answer to me. In any way the method has to be called like this:
var x = antenna()
x.extend()
So what's the point of separating the the struct and methods? Having them visually grouped together in the code - as in typical OOP languages - seems useful to me?
go methods struct
go methods struct
asked Nov 20 '18 at 6:18
MuppetMuppet
1,96531627
asked Nov 20 '18 at 6:18
MuppetMuppet
1,96531627
edited Nov 20 '18 at 6:27
Muppet
asked Nov 20 '18 at 6:18
MuppetMuppet
1,96531627
asked Nov 20 '18 at 6:18
MuppetMuppet
1,96531627
asked Nov 20 '18 at 6:18
MuppetMuppet
1,96531627
1,96531627
3
You can't just ignore the difference between value and pointer receivers. This is important. Not all methods mutate the receiver. See time.Time for a prolific example. It's also very useful to be able put types and methods in separate files. This enabled easy code generation and architecture specific implementations.
– Peter
Nov 20 '18 at 6:42
5
Any named type can have methods, not just struct types.
– ThunderCat
Nov 20 '18 at 6:54
"This would be more similar to traditional OOP" -- So what? Go isn't OOP.
– Flimzy
Nov 20 '18 at 7:49
add a comment |
3
You can't just ignore the difference between value and pointer receivers. This is important. Not all methods mutate the receiver. See time.Time for a prolific example. It's also very useful to be able put types and methods in separate files. This enabled easy code generation and architecture specific implementations.
– Peter
Nov 20 '18 at 6:42
5
Any named type can have methods, not just struct types.
– ThunderCat
Nov 20 '18 at 6:54
"This would be more similar to traditional OOP" -- So what? Go isn't OOP.
– Flimzy
Nov 20 '18 at 7:49
3
3
You can't just ignore the difference between value and pointer receivers. This is important. Not all methods mutate the receiver. See time.Time for a prolific example. It's also very useful to be able put types and methods in separate files. This enabled easy code generation and architecture specific implementations.
– Peter
Nov 20 '18 at 6:42
You can't just ignore the difference between value and pointer receivers. This is important. Not all methods mutate the receiver. See time.Time for a prolific example. It's also very useful to be able put types and methods in separate files. This enabled easy code generation and architecture specific implementations.
– Peter
Nov 20 '18 at 6:42
5
5
Any named type can have methods, not just struct types.
– ThunderCat
Nov 20 '18 at 6:54
Any named type can have methods, not just struct types.
– ThunderCat
Nov 20 '18 at 6:54
"This would be more similar to traditional OOP" -- So what? Go isn't OOP.
– Flimzy
Nov 20 '18 at 7:49
"This would be more similar to traditional OOP" -- So what? Go isn't OOP.
– Flimzy
Nov 20 '18 at 7:49
add a comment |
2 Answers
2
active
oldest
votes
My Viewpoints:
1. It is simpler this way and makes language consistent/uniform for struct types and other types like following code.
2. You don't need this or self pointer to use and you name it as you wish, and this makes it even simpler to explain what is p (in your example).
Also may be this is relevant:
In Go is naming the receiver variable 'self' misleading or good practice?
You may define your own types, See this sample (There is no inside or struct here for this named type):
package main
import "fmt"
type num int32
func (p *num) inc() {
*p++
}
func main() {
p := num(100)
p.inc()
fmt.Println(p) // 101
}
answered Nov 20 '18 at 6:40
aramazaniaramazani
2,0802920
Hi, thanks for your answer. I still don't understand why having the option to define methods inside the struct def would be bad? In C# for example you can define methods both outside and inside and both arrangements have benefits. C# also has value types and the syntax for defining methods is the same as for reference types. So why only allow the methods outside the struct?
– Muppet
Nov 20 '18 at 16:56
@Muppet: it is not bad! It is just by design. each language has its own pros and cons. There are many languages to learn today and one developer should learn many! to get the job done so the inventors of the google decided to build one new fast and simple one! it is simpler than some languages yet has many details to learn and after 3 years I'm still learning Golang! it never ends! and see this COMPOSITION OVER INHERITANCE. I hope this helps.
– aramazani
Nov 20 '18 at 18:37
add a comment |
In golang, if we need a function associated with a type (say struct), then it must be defined as below (here is for go struct):
type my_type struct {
// fields ...
}
func (m my_type) fn_name(fn_parameters) fn_return_type {
// do whatever we want
}
It's not something you define in your own way. But the identifier's names can be used as we want.
answered Nov 20 '18 at 7:09
Shudipta SharmaShudipta Sharma
1,037312
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53387303%2fwhats-the-reason-for-having-methods-outside-the-definition-of-the-struct%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
My Viewpoints:
1. It is simpler this way and makes language consistent/uniform for struct types and other types like following code.
2. You don't need this or self pointer to use and you name it as you wish, and this makes it even simpler to explain what is p (in your example).
Also may be this is relevant:
In Go is naming the receiver variable 'self' misleading or good practice?
You may define your own types, See this sample (There is no inside or struct here for this named type):
package main
import "fmt"
type num int32
func (p *num) inc() {
*p++
}
func main() {
p := num(100)
p.inc()
fmt.Println(p) // 101
}
answered Nov 20 '18 at 6:40
aramazaniaramazani
2,0802920
Hi, thanks for your answer. I still don't understand why having the option to define methods inside the struct def would be bad? In C# for example you can define methods both outside and inside and both arrangements have benefits. C# also has value types and the syntax for defining methods is the same as for reference types. So why only allow the methods outside the struct?
– Muppet
Nov 20 '18 at 16:56
@Muppet: it is not bad! It is just by design. each language has its own pros and cons. There are many languages to learn today and one developer should learn many! to get the job done so the inventors of the google decided to build one new fast and simple one! it is simpler than some languages yet has many details to learn and after 3 years I'm still learning Golang! it never ends! and see this COMPOSITION OVER INHERITANCE. I hope this helps.
– aramazani
Nov 20 '18 at 18:37
add a comment |
My Viewpoints:
1. It is simpler this way and makes language consistent/uniform for struct types and other types like following code.
2. You don't need this or self pointer to use and you name it as you wish, and this makes it even simpler to explain what is p (in your example).
Also may be this is relevant:
In Go is naming the receiver variable 'self' misleading or good practice?
You may define your own types, See this sample (There is no inside or struct here for this named type):
package main
import "fmt"
type num int32
func (p *num) inc() {
*p++
}
func main() {
p := num(100)
p.inc()
fmt.Println(p) // 101
}
answered Nov 20 '18 at 6:40
aramazaniaramazani
2,0802920
Hi, thanks for your answer. I still don't understand why having the option to define methods inside the struct def would be bad? In C# for example you can define methods both outside and inside and both arrangements have benefits. C# also has value types and the syntax for defining methods is the same as for reference types. So why only allow the methods outside the struct?
– Muppet
Nov 20 '18 at 16:56
@Muppet: it is not bad! It is just by design. each language has its own pros and cons. There are many languages to learn today and one developer should learn many! to get the job done so the inventors of the google decided to build one new fast and simple one! it is simpler than some languages yet has many details to learn and after 3 years I'm still learning Golang! it never ends! and see this COMPOSITION OVER INHERITANCE. I hope this helps.
– aramazani
Nov 20 '18 at 18:37
add a comment |
My Viewpoints:
1. It is simpler this way and makes language consistent/uniform for struct types and other types like following code.
2. You don't need this or self pointer to use and you name it as you wish, and this makes it even simpler to explain what is p (in your example).
Also may be this is relevant:
In Go is naming the receiver variable 'self' misleading or good practice?
You may define your own types, See this sample (There is no inside or struct here for this named type):
package main
import "fmt"
type num int32
func (p *num) inc() {
*p++
}
func main() {
p := num(100)
p.inc()
fmt.Println(p) // 101
}
answered Nov 20 '18 at 6:40
aramazaniaramazani
2,0802920
My Viewpoints:
1. It is simpler this way and makes language consistent/uniform for struct types and other types like following code.
2. You don't need this or self pointer to use and you name it as you wish, and this makes it even simpler to explain what is p (in your example).
Also may be this is relevant:
In Go is naming the receiver variable 'self' misleading or good practice?
You may define your own types, See this sample (There is no inside or struct here for this named type):
package main
import "fmt"
type num int32
func (p *num) inc() {
*p++
}
func main() {
p := num(100)
p.inc()
fmt.Println(p) // 101
}
answered Nov 20 '18 at 6:40
aramazaniaramazani
2,0802920
edited Nov 20 '18 at 7:24
answered Nov 20 '18 at 6:40
aramazaniaramazani
2,0802920
answered Nov 20 '18 at 6:40
aramazaniaramazani
2,0802920
answered Nov 20 '18 at 6:40
aramazaniaramazani
2,0802920
2,0802920
Hi, thanks for your answer. I still don't understand why having the option to define methods inside the struct def would be bad? In C# for example you can define methods both outside and inside and both arrangements have benefits. C# also has value types and the syntax for defining methods is the same as for reference types. So why only allow the methods outside the struct?
– Muppet
Nov 20 '18 at 16:56
@Muppet: it is not bad! It is just by design. each language has its own pros and cons. There are many languages to learn today and one developer should learn many! to get the job done so the inventors of the google decided to build one new fast and simple one! it is simpler than some languages yet has many details to learn and after 3 years I'm still learning Golang! it never ends! and see this COMPOSITION OVER INHERITANCE. I hope this helps.
– aramazani
Nov 20 '18 at 18:37
add a comment |
Hi, thanks for your answer. I still don't understand why having the option to define methods inside the struct def would be bad? In C# for example you can define methods both outside and inside and both arrangements have benefits. C# also has value types and the syntax for defining methods is the same as for reference types. So why only allow the methods outside the struct?
– Muppet
Nov 20 '18 at 16:56
@Muppet: it is not bad! It is just by design. each language has its own pros and cons. There are many languages to learn today and one developer should learn many! to get the job done so the inventors of the google decided to build one new fast and simple one! it is simpler than some languages yet has many details to learn and after 3 years I'm still learning Golang! it never ends! and see this COMPOSITION OVER INHERITANCE. I hope this helps.
– aramazani
Nov 20 '18 at 18:37
Hi, thanks for your answer. I still don't understand why having the option to define methods inside the struct def would be bad? In C# for example you can define methods both outside and inside and both arrangements have benefits. C# also has value types and the syntax for defining methods is the same as for reference types. So why only allow the methods outside the struct?
– Muppet
Nov 20 '18 at 16:56
Hi, thanks for your answer. I still don't understand why having the option to define methods inside the struct def would be bad? In C# for example you can define methods both outside and inside and both arrangements have benefits. C# also has value types and the syntax for defining methods is the same as for reference types. So why only allow the methods outside the struct?
– Muppet
Nov 20 '18 at 16:56
@Muppet: it is not bad! It is just by design. each language has its own pros and cons. There are many languages to learn today and one developer should learn many! to get the job done so the inventors of the google decided to build one new fast and simple one! it is simpler than some languages yet has many details to learn and after 3 years I'm still learning Golang! it never ends! and see this COMPOSITION OVER INHERITANCE. I hope this helps.
– aramazani
Nov 20 '18 at 18:37
@Muppet: it is not bad! It is just by design. each language has its own pros and cons. There are many languages to learn today and one developer should learn many! to get the job done so the inventors of the google decided to build one new fast and simple one! it is simpler than some languages yet has many details to learn and after 3 years I'm still learning Golang! it never ends! and see this COMPOSITION OVER INHERITANCE. I hope this helps.
– aramazani
Nov 20 '18 at 18:37
add a comment |
In golang, if we need a function associated with a type (say struct), then it must be defined as below (here is for go struct):
type my_type struct {
// fields ...
}
func (m my_type) fn_name(fn_parameters) fn_return_type {
// do whatever we want
}
It's not something you define in your own way. But the identifier's names can be used as we want.
answered Nov 20 '18 at 7:09
Shudipta SharmaShudipta Sharma
1,037312
add a comment |
In golang, if we need a function associated with a type (say struct), then it must be defined as below (here is for go struct):
type my_type struct {
// fields ...
}
func (m my_type) fn_name(fn_parameters) fn_return_type {
// do whatever we want
}
It's not something you define in your own way. But the identifier's names can be used as we want.
answered Nov 20 '18 at 7:09
Shudipta SharmaShudipta Sharma
1,037312
add a comment |
In golang, if we need a function associated with a type (say struct), then it must be defined as below (here is for go struct):
type my_type struct {
// fields ...
}
func (m my_type) fn_name(fn_parameters) fn_return_type {
// do whatever we want
}
It's not something you define in your own way. But the identifier's names can be used as we want.
answered Nov 20 '18 at 7:09
Shudipta SharmaShudipta Sharma
1,037312
In golang, if we need a function associated with a type (say struct), then it must be defined as below (here is for go struct):
type my_type struct {
// fields ...
}
func (m my_type) fn_name(fn_parameters) fn_return_type {
// do whatever we want
}
It's not something you define in your own way. But the identifier's names can be used as we want.
answered Nov 20 '18 at 7:09
Shudipta SharmaShudipta Sharma
1,037312
answered Nov 20 '18 at 7:09
Shudipta SharmaShudipta Sharma
1,037312
answered Nov 20 '18 at 7:09
Shudipta SharmaShudipta Sharma
1,037312
answered Nov 20 '18 at 7:09
Shudipta SharmaShudipta Sharma
1,037312
1,037312
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53387303%2fwhats-the-reason-for-having-methods-outside-the-definition-of-the-struct%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
3
You can't just ignore the difference between value and pointer receivers. This is important. Not all methods mutate the receiver. See time.Time for a prolific example. It's also very useful to be able put types and methods in separate files. This enabled easy code generation and architecture specific implementations.
– Peter
Nov 20 '18 at 6:42
5
Any named type can have methods, not just struct types.
– ThunderCat
Nov 20 '18 at 6:54
"This would be more similar to traditional OOP" -- So what? Go isn't OOP.
– Flimzy
Nov 20 '18 at 7:49