4 ms·
Embedding like this will only lead to pain long term. It's preferable to implement the interface you want to fulfil directly (by having actual method definition
by AYBABTME 7y ago
Embedding like this will only lead to pain long term. It's preferable to implement the interface you want to fulfil directly (by having actual method definitions), despite the extra ceremony. Inheritance with embedding is a false friend in Go. Stick to composition.
If you want to delegate a call to a "subtype", simply invoke the method on the subtype by writing it out in long form. It doesn't make you feel as intelligent but it's way more robust and won't come back to bite you down the line.
- weberc2 7y ago> Inheritance with embedding is a false friend in Go. Stick to composition. Note that this applies to every language with inheritance. Composition is _always_ better.
- whateveracct 7y agoSometimes you need this though. For instance, if you do a type alias on a UUID, it will fail to marshal to SQL. But if you do a singleton embedded struct, it will work fine. I'm not gonna waste my time writing Scan and Value every time I newtype
- thinkingkong 7y agoAre there any cases where you would make use of this?
- edem 7y agoUsing Go will lead to pain long term, so I don't think any of this matters. :)