4 ms·
One thing he says I think is incorrect. "interface{} is a code smell unless your function truly takes anything" seems wrong to me because I frequently find mys
by TheDong 12y ago
One thing he says I think is incorrect.
"interface{} is a code smell unless your function truly takes anything" seems wrong to me because I frequently find myself using interface anytime my function can take multiply typed maps or slices (as a substitute for a generic) and I don't think you can use an expression to indicate all slices of all types.
In that case, you start with a type assertion using reflection (is a slice of something) but you can't avoid taking an interface.
It's a minor nit; overall this article is very well written and rings true.
- TheHydroImpulse 12y agoWhile I'm not a Go programmer, the reason it should be a code smell is because you lose type safety and incur a run-time penalty cost for using reflections. Perhaps the things people build in Go will make the later point moot, but the former shouldn't.
- TheDong 12y agoOh, I absolutely agree it's bad to lose type safety, but you have to realize that go does not give you another option. When you want to do something that takes a "generic" slice, you don't have generics. If you're using reflection, you're already so far out in left field in terms of safety that you might as well just give up on your type safety because you don't have any other safety either. I fully agree that this is bad, but sicne Go is not a good language it's what you do and thus this is not a code smell in Go, but rather an artifact of Go lacking generics.
- wyager 12y agoIt's code smell because you're subverting the type system, and your program is not checked to be type-safe.
- coldtea 12y ago>"interface{} is a code smell unless your function truly takes anything" seems wrong to me because I frequently find myself using interface anytime my function can take multiply typed maps or slices (as a substitute for a generic) and I don't think you can use an expression to indicate all slices of all types. It's still a code smell -- just one that's made necessary to add for certain cases by the language (for the lack of better mechanisms).
- jerf 12y agoIt's a "code smell" and not an "error" for that reason. You can't always eliminate code smells, but you should always be keeping an, errr, nose on them. (Keep an eye on them isn't quite right, is it?)