Hey Flo, just wanted to say how much I like your teaching style. Your videos are great! Please cover more advanced Golang topics such as Go concurrency patterns and best practices. Thank you!
Nice video, but on the language accordance with logic of interface design, let's said that a Shape has a perimeter. So it does reduce the understand about what is the idea to implement a new interface to any duty contract. I would better think about Position as a new interface. Because a shape will have any area, perimeter by logic. But the position it can have is not due to the fact it is a shape, but because this shape can be somewhere. So, for example, An interface named Object can be the resulted union about Shape and Position. This (in my mind) is the way to think about contract interface in Golang (and most probably, in interface in general). Tell me if you are ok with this observation, please.
Thanks for the video, the explanations are easy to understand. One thing I didn't fully get is how by passing the CalculationError{msg: "Invalid input"} struct instance on the performCalculation() the performCalculation() would use the Error() method of the CalculationError struct, I would've thought that we would need to call the Error() method of the struct but this is not the case, so what I gather with this is that the compiler implicitly deduces that since we are returning a value of type error and because we're using the CalculationError{msg: "Invalid input value"} struct instance as its return value it "sees" that this struct instance has a method that implements the Error() function and hence it uses it. So this is some sort of implicit default method for specific type returns or something like that, I honestly don't no how to refer to this behavior, I had no knowledge if this behavior but is good to know. Thanks again for putting this video together.
The kind of thinking of interfaces being a contract is not wrong, but kinda abstract. Think of an interface as a membership, named after whatever you decide to call your interface, in this case "Shape". For any struct/class that wants to have that membership, they have to implement the functions described in that interface, much like how you may want to meet certain criteria to have a gym membership. So for Circle and Rectangle, they have to implement all Shape functions/methods to have a Shape membership. This is convenient because perhaps there could be a function somewhere that only takes Shape members to operate on them (calculateArea), and if Circle and Rectangle are Shape members, that function can operate on either one of them
As far as I've understood it, they're basically like a class in C++ where everything is virtual. Generally we'd refer to that as an abstract class. That and error codes instead of exceptions I copied as features for my own language. I don't like that they use it as a sort of replacement for genericity syntax though. It's basically another void pointer, but with the requirements for casting turned 180 degrees. So better, but not good enough in my opinion. Looks like you do both Rust and Go, but perhaps you should add more languages to your repertoire like plain C and demonstrate how different constructs work at a fundamental level by converting them to C.
If you want to make it clear that a struct implements a particular interface, you can do a compile time assertion. var _ MyInterface = (*MyStruct)(nil) So you get the explicitness while still allowing consumers to define their own interfaces for which your struct can also satisfy. Not saying to do this, just sharing some knowledge.
Hey Flo, just wanted to say how much I like your teaching style. Your videos are great! Please cover more advanced Golang topics such as Go concurrency patterns and best practices. Thank you!
Thank you so much for the great feedback!
Go Concurrency patterns is definitely a video on my todo list :)
I've been struggling with how interfaces work for a while now and I think this video finally got it to click for me. Thank you.
I am glad to hear that!
This teacher is so logical, thanks!!
Thank you :D
Nice video, but on the language accordance with logic of interface design, let's said that a Shape has a perimeter. So it does reduce the understand about what is the idea to implement a new interface to any duty contract.
I would better think about Position as a new interface. Because a shape will have any area, perimeter by logic. But the position it can have is not due to the fact it is a shape, but because this shape can be somewhere. So, for example, An interface named Object can be the resulted union about Shape and Position.
This (in my mind) is the way to think about contract interface in Golang (and most probably, in interface in general).
Tell me if you are ok with this observation, please.
Your videos are amazing.
Thank you so much! :)
Thanks for the video, the explanations are easy to understand. One thing I didn't fully get is how by passing the CalculationError{msg: "Invalid input"} struct instance on the performCalculation() the performCalculation() would use the Error() method of the CalculationError struct, I would've thought that we would need to call the Error() method of the struct but this is not the case, so what I gather with this is that the compiler implicitly deduces that since we are returning a value of type error and because we're using the CalculationError{msg: "Invalid input value"} struct instance as its return value it "sees" that this struct instance has a method that implements the Error() function and hence it uses it. So this is some sort of implicit default method for specific type returns or something like that, I honestly don't no how to refer to this behavior, I had no knowledge if this behavior but is good to know.
Thanks again for putting this video together.
I've never seen someone explain something that clearly
Wow, thank you! :)
The kind of thinking of interfaces being a contract is not wrong, but kinda abstract.
Think of an interface as a membership, named after whatever you decide to call your interface, in this case "Shape". For any struct/class that wants to have that membership, they have to implement the functions described in that interface, much like how you may want to meet certain criteria to have a gym membership.
So for Circle and Rectangle, they have to implement all Shape functions/methods to have a Shape membership. This is convenient because perhaps there could be a function somewhere that only takes Shape members to operate on them (calculateArea), and if Circle and Rectangle are Shape members, that function can operate on either one of them
That's also a nice way to see it, except that I can always have a membership of something without meeting any requirement or using the membership :D
As far as I've understood it, they're basically like a class in C++ where everything is virtual. Generally we'd refer to that as an abstract class. That and error codes instead of exceptions I copied as features for my own language. I don't like that they use it as a sort of replacement for genericity syntax though. It's basically another void pointer, but with the requirements for casting turned 180 degrees. So better, but not good enough in my opinion. Looks like you do both Rust and Go, but perhaps you should add more languages to your repertoire like plain C and demonstrate how different constructs work at a fundamental level by converting them to C.
Nice explanation my friend!
Thank you! Cheers!
thanks
Sure thing :)
Very nice! Thank you +sub
Thank you! :)
Thanks This helped a lot.
I am glad it helped :)
Thanks so much 💝 this really helped me, keep on goin
You're welcome 😊
Nice explanation. Thanks. Subscribed.
Awesome, thank you!
Nice explanation, please bring video on golang projects too
Thank you! I'll try my best :)
excellent..Thx a lot
Thank you for watching :)
This was great!
I am glad you've liked it :)
What is the font name?
I am using `monaspace` :)
I knew I could rely on this already being asked 😂
👌
implicit implementation of interfaces is a bit weird in Go. Would prefer the rusty way!
I prefer the explicit interface implementation as well, because things are much clearer.
If you want to make it clear that a struct implements a particular interface, you can do a compile time assertion.
var _ MyInterface = (*MyStruct)(nil)
So you get the explicitness while still allowing consumers to define their own interfaces for which your struct can also satisfy.
Not saying to do this, just sharing some knowledge.
@@jordanhasgul4401 Damm didn't know this, thanks!