Re-posting to the list. On Mon, 31 Jul 2017, 14:15 roger peppe, <rogpe...@gmail.com> wrote:
> On 30 July 2017 at 08:22, Tristan Colgate <tcolg...@gmail.com> wrote: > >> >> >> On Sat, 29 Jul 2017, 23:59 Shawn Milochik, <shawn.m...@gmail.com> wrote: >> >>> >>> - You don't need generics to write Kubernetes. >>> >>> I've had no personal need for generics, but k8s client-go is the one >> case I've seen where I thought they would help, the informers packages in >> particular. >> >> https://godoc.org/k8s.io/client-go >> > > It's always nice to have experience reports of real world cases, so > could you expand on this, please? What specific code are you referring to > here, > and how would it be improved if Go had generics? > I should start by saying that I'm not a contributor to client-go, just a user, so can't speak for their actual experience of developing that package. As I understand it, much of client-go is generated by tools already, so they have the particular problem solved, and may well be far happier with what they have than a generics solution. The particular package that triggered the "generics" sensation is http://godoc.org/k8s.io/client-go/informers and http://godoc.org/k8s.io/client-go/listers. These generate code for efficiently watchig and listing resources on kube cluster using a nice cacheing mechanism. All of the individual type specific informers packages have a func New(f internalinterfaces.SharedInformerFactory) Interface Interface here is a type in the package such as type Interface interface { // HorizontalPodAutoscalers returns a HorizontalPodAutoscalerInformer. HorizontalPodAutoscalers() HorizontalPodAutoscalerInformer } which provides a type-safe way of getting at a the thing being informed on. Part of me imagines someting like.. import hpaInformer informer<v2alpha1.HorizontalPodAutoscaler> myInformer := hpaInformer.New(sharedUnderlyingCacheThing) My hunch is that client-go has quite a few of these situations (the listers package is one, and general experience with the package suggests there would be others). Clearly everything is already working pretty well, so there's nothing "impossible" without generics here. The client-go package is still reasonably pleasant to use (though, as a consequence of all the genration the docs are very verbose, but low content, it took me a long time to actually work out how to use the shared informers stuff because I kept start with the voluminous sub packages, rather than the informers package that got lost in the noise). And, once again, I'm heavily unqualified to comment on this from the package maintainers PoV, if they felt strongly about this, I'm sure they'd be speaking up already. > > -- 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 golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
