4 ms·
Without generics you'll need to use an alternative approach. As you said you can use interface{} everywhere. Another option is to create an interface that does
by cdoxsey 13y ago
Without generics you'll need to use an alternative approach. As you said you can use interface{} everywhere. Another option is to create an interface that does what you need. Checkout "sort" for an example: http://golang.org/pkg/sort/#Interface http://golang.org/pkg/sort/#Interface.
- coldtea 13y agoI think he already covered both, the second with "or I have to write my own separate implementation for every and each type of graph I'll use, without any significant way to reuse code".
- dubbledidu 13y agoSort is just one instance where one can work around Go's limitations, this is not repeatable in general.
- drdaeman 13y agoSure, I can `type Tree struct { Child []*Tree; Node NodeType }`, where `NodeType` is either `interface{}` (makes `Tree` reusable by sacrificing type safety) or some concrete type (sacrifices `Tree`'s reuse) but that's about how far I can progress. Also, I have to manually ensure that only one of Child or Node is set, but not both. I just can't do anything like `data Tree a = Leaf a | Node [Tree a]` there. (Edit: okay, my mind swayed a bit, that was trees, not graphs. I had different ideas on data structure to use, and my memories are a bit messy. Sorry about this. The problem should still hold, it applies to both trees and graphs, and I think many other data structures too.)
- cdoxsey 13y agoThe 'one of Child or Node' isn't really an issue since you probably shouldn't expose the members of the struct (the tree should be accessed via methods). But I agree with your point about containers.