3 ms·
You're still writing separate functions (implementations of sort.Interface) to sort different types.
by pcwalton 9y ago
You're still writing separate functions (implementations of sort.Interface) to sort different types.
- dualogy 9y agoA little boilerplate hasn't killed anyone. If you're talking about "100s of different Enterprise Business Objects (TM) structs", something is probably off in the overall program design and/or code-gen should probably be introduced regardless of the 'sort' (and related typically-generics use-cases) question, as that sounds like something to be largely derived from pre-existing schemas of some sort..
- pcwalton 9y ago> A little boilerplate hasn't killed anyone. It's annoying, especially since basic generics are simpler than interfaces. > If you're talking about "100s of different Enterprise Business Objects (TM) structs" I don't write enterprise software. I sometimes need to sort things.
- ori_b 9y agoBut this is something you often need to do for any non-trivial type, even with generics. There's a reason that C++ std::sort<> takes a comparator, or why Rust requires you to implement the 'Ord' interface. Again, it's a little clunkier in Go, but not unusably so.
- pcwalton 9y agoYou need to define how to order things in other languages (though not in languages where you can automatically derive implementations like Haskell or languages with built-in polymorphic comparison like OCaml) but you don't need to define how to swap elements over and over.
- ori_b 9y agoYes, I'm aware. That's the clunky part that I was referring to (although, you can still avoid it for slices, and simply pass a single compare function.) Go is far from my favorite language, but the sheer amount of bad criticism by people that clearly don't use the language annoys me.
- fauigerzigerk 9y agoFor sorting slices you only have to pass one function: sort.Slice(s, func(i, j int) bool { return s[i].X < s[j].X })