4 ms·

That is SO disturbing... They don't even check whether the parameter implements another interface, they do the check directly on the method by callin it... That

by bsaul 13y ago

That is SO disturbing... They don't even check whether the parameter implements another interface, they do the check directly on the method by callin it... That's so ugly... Reminds me of my surprise when i realized the math module only worked on float types, and that min/max only existed for some numerical types but not others. The thing in itself probably isn't a big deal, but it really questions the ability of the language to model complex relationships often found in business processes.

thirsteh 13y ago
> That is SO disturbing... They don't even check whether the parameter implements another interface, they do the check directly on the method by callin it... That's so ugly... That's incorrect. The code you see at the top: if rt, ok := dst.(ReaderFrom); ok { return rt.ReadFrom(src) } means: "If dst implements ReaderFrom, then call ReadFrom on this value of that type." You can't arbitrarily call methods that may or may not exist. You can check if a value implements an interface by doing "newVal, ok := val.(suspectedInterface)", and checking if ok is true, or by doing "newVal := val.(suspectedInterface)" and living with a runtime panic if it doesn't implement the interface, then call a method in that interface on the new value newVal, which will be of type suspectedInterface. (If val doesn't implement suspectedInterface--i.e. ok is false--then newVal will be the zero value of suspectedInterface.)
- bsaul 13y ago
  yeap, i read it too fast. Didn't notice the "er" after dst. thanks for clarifying.