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 at 6:18
Muppet
1,93531626
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 at 6:18
Muppet
1,93531626
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 at 6:42
5
Any named type can have methods, not just struct types.
– ThunderCat
Nov 20 at 6:54
"This would be more similar to traditional OOP" -- So what? Go isn't OOP.
– Flimzy
Nov 20 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 at 6:18
Muppet
1,93531626
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 at 6:18
Muppet
1,93531626
asked Nov 20 at 6:18
Muppet
1,93531626
edited Nov 20 at 6:27
asked Nov 20 at 6:18
Muppet
1,93531626
asked Nov 20 at 6:18
Muppet
1,93531626
asked Nov 20 at 6:18
Muppet
1,93531626
1,93531626
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 at 6:42
5
Any named type can have methods, not just struct types.
– ThunderCat
Nov 20 at 6:54
"This would be more similar to traditional OOP" -- So what? Go isn't OOP.
– Flimzy
Nov 20 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 at 6:42
5
Any named type can have methods, not just struct types.
– ThunderCat
Nov 20 at 6:54
"This would be more similar to traditional OOP" -- So what? Go isn't OOP.
– Flimzy
Nov 20 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 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 at 6:42
5
5
Any named type can have methods, not just struct types.
– ThunderCat
Nov 20 at 6:54
Any named type can have methods, not just struct types.
– ThunderCat
Nov 20 at 6:54
"This would be more similar to traditional OOP" -- So what? Go isn't OOP.
– Flimzy
Nov 20 at 7:49
"This would be more similar to traditional OOP" -- So what? Go isn't OOP.
– Flimzy
Nov 20 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 at 6:40
A.R
2,0102920
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 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.
– A.R
Nov 20 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 at 7:09
Shudipta Sharma
1,025312
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 at 6:40
A.R
2,0102920
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 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.
– A.R
Nov 20 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 at 6:40
A.R
2,0102920
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 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.
– A.R
Nov 20 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 at 6:40
A.R
2,0102920
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 at 6:40
A.R
2,0102920
edited Nov 20 at 7:24
answered Nov 20 at 6:40
A.R
2,0102920
answered Nov 20 at 6:40
A.R
2,0102920
answered Nov 20 at 6:40
A.R
2,0102920
2,0102920
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 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.
– A.R
Nov 20 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 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.
– A.R
Nov 20 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 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 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.
– A.R
Nov 20 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.
– A.R
Nov 20 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 at 7:09
Shudipta Sharma
1,025312
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 at 7:09
Shudipta Sharma
1,025312
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 at 7:09
Shudipta Sharma
1,025312
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 at 7:09
Shudipta Sharma
1,025312
answered Nov 20 at 7:09
Shudipta Sharma
1,025312
answered Nov 20 at 7:09
Shudipta Sharma
1,025312
answered Nov 20 at 7:09
Shudipta Sharma
1,025312
1,025312
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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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 at 6:42
5
Any named type can have methods, not just struct types.
– ThunderCat
Nov 20 at 6:54
"This would be more similar to traditional OOP" -- So what? Go isn't OOP.
– Flimzy
Nov 20 at 7:49