|| at Jul 9, 2014 at 1:19 pm
That's the way the sort package works, regarding most of your concerns :
- data containers are not receiver of method Sort
- method Sort expect the data container as argument, which must implement
- clients must implement methods Len,Less,Swap for each different container
- sort algorithm is written only in package sort, not for each type to be
- no embedding needed
Whether this must be regarded as elegant or not was not my point, I say
this is among the idiomatic go practices because a well-informed gopher
told me : generics are not a missing feature, interfaces are the generics.
On Wednesday, July 9, 2014 2:36:06 PM UTC+2, Eugene Toropov wrote:
Sorry, but I don't feel it's a good way and of course it's not a Go way.
Unless you can show me where it's done this way on github of course.
On Wednesday, July 9, 2014 4:16:51 PM UTC+4, Val wrote:
Indeed, type Xer cannot be the method receiver, so it has to be a method
I agree it looks more "procedural" than OO but it still achieves
polymorphism (we don't have to care about the underlying type of the
object, as long as it implements Xer) and it still avoids to duplicate
methods again and again.
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to email@example.com.
For more options, visit https://groups.google.com/d/optout.