hash.Function? Then you need print.Function. So soon enough there will be a 1000 interfaces named Function that have nothing to do with hashing or printing because everything can be decomposed that way.
context.Frame? Now you’re just being silly. You might as well use context.Instance or even Function... This an issue because of the reluctance to properly support the dot import (or something like it). Then you would just have Context, which for core types is what you want. If you have a specialized Context then it should be fully qualified. It’s comforting to know that Go will end with 1.x because 2.0 is going to be designed by committee and is going to stink. Too many people talking just to hear themselves. Forget the “rules” and focus on writing software that is easy to read, write and maintain. You’ll know it when you see it. APIs are hard. Leave it to the practical professionals. > On Dec 1, 2018, at 2:46 AM, Dan Kortschak <d...@kortschak.io> wrote: > > Very nice. > >> On Sat, 2018-12-01 at 00:16 -0800, Anthony Martin wrote: >> Nigel Tao <nigel...@golang.org> once said: >>> >>> Well, there's already context.Context, hash.Hash, image.Image and >>> time.Time in the standard library. >> All of which are not great. Better names are context.Frame, >> hash.Function, raster.Image, and time.Instant. >> >> Anthony >> > > -- > 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. -- 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.
