4 ms·
i feel like that C example isnt fair cause you cant have functions bound to types right?? youre not calling change(a) but instead calling a.change(). i havent
by wara23arish 4y ago
i feel like that C example isnt fair cause you cant have functions bound to types right??
youre not calling change(a) but instead calling a.change().
i havent learned any rust yet, im waiting till im a little better at go so i can be comfortable at work before doing so:)
whats the advantage of creating a function of type struct a rather than creating the C equivalent of change(obj structAtype) ? to me now, it seems that it should be expected that an a.Change func will mutate A
i see what you’re saying that with Go it cant always be easy to check if its mutating what you’re calling or not. its giving the developer more options to use stuff by ref/val which gives more power but more room for mistakes.
- kevinmgranger 4y ago> it seems that it should be expected that an a.Change func will mutate A But you can make functions that have copied receivers: type Foo struct { bar int } func (f Foo) mutate() { f.bar = 2 } func main() { f := Foo{bar: 1} f.mutate() fmt.Println(f.bar) // 1 } > whats the advantage of creating a function of type struct a rather than creating the C equivalent of change(obj structAtype) types need to have methods in order to fulfill interfaces, that's all. (Well, and all the downstream benefits of using interfaces, such a polymorphism).
- wara23arish 4y agoOkay, I haven’t worked with Go enough yet to need inheritance so I stupidly overlooked that :) even though ive used it extensively in java. i can definitely see how that is wacky. i wonder what the upsides of being able to do that is. really appreciate the explanation! thank you