On Wednesday, 29 June 2016 06:35:03 UTC+3, Egon wrote: > > On Wednesday, 29 June 2016 01:51:58 UTC+3, Mandolyte wrote: >> >> Earlier someone asked about real world examples. The obvious standard >> library was mentioned. It only took me a few seconds to remember Jan >> Mercl's interval package. A quick look suggests that the current 1200+ >> lines of code would be reduced to about 250. > > > I'm not sure what application would require that full extent of the > interval package. Currently the only thing I see importing it was > https://godoc.org/github.com/cznic/wm, but it only used only one func > from it... so the whole package could be replaced with ~10 lines. > > So the problem is that I don't know a real-world use-case for that package > -- hence I cannot judge it's API design and quality. Sure the interval > package might be necessary, but is there a simpler design? Is the > genericness of that package even warranted? How would it affect user code > by making it generic. Are there alternate designs? Should it implement a > tree instead? > > If this sort of code is written very often, the "prove it to me" argument >> against generics will be less effective. >> >> So, how about some more examples? >> > Just to be clear what I consider a *great example* for analyzing generics:
1. a package containing something non-trivial and generic * alternatively, multiple packages that could have benfitted from that generic design* 2. 3+ real-world packages/applications use that package * By real-world here I mean it wasn't written for learning or fun, but rather solving a concrete problem.* 3. the package is specialized with at least 4 different types * ~4 types is where manual management of specializations becomes too verbose* 4. the package is implemented "in the best way" * e.g. linked list would be a bad example, because it's usually a bad solution <https://www.youtube.com/watch?v=YQs6IC-vgmo> in the first place* 5. the package using it, is written "in the best way" * e.g. code using a custom implementation of map without a good reason is a bad example* Reasoning for those points, *1.* is just the baseline implementation and ensures that the specializations can use a non-trivial amount of code; *2.* ensures that package 1. is actually valuable in practice; *3.* ensures that the package would benefit from generics; *4./5.* are mainly for discussion and whether the right problem was solved, maybe 1. can be significantly simplified or is unnecessary. *PS: I'm not saying there isn't value in smaller examples, but when all listed conditions are met, then it's easier to analyse what trade-offs can be made and how those will affect code using it.* + Egon -- 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.
