> Generics enable more than just replacing loops. For example, they can enable libraries of generic algorithms to be used with any type of array. Here's an example:
in my demonstration every type got this kind of method, the problem become how do you jump from Type A to type B. in []A to []B or A -> B indeed it works on the item level, no more on the collections. This question is solved in two ways, - interface definitions (not interface value) - static conversion, which always resumes to func(in-type) out-type and some alternatives for convenience (producer/consumer) func (func(in-type) out-type func (in-type) func() out-type func (func(in-type) func() out-type // this is unfinished explanation it should include error management to be handled more completely. see please previous conv() fn introduced earlier to statically re decorate a func signature. So far the sum/reduce things operation, i left them as exercise to the stream declarer and did not consider them as core. Take become => filter (func(10 elements)) Map is map Sort is All(fn sorter) []out Reduce is a map operation, preceded by a conv if it reduces to a different type. On Friday, June 2, 2017 at 2:59:41 PM UTC+2, gary.wi...@victoriaplumb.com wrote: > > Generics enable more than just replacing loops. For example, they can > enable libraries of generic algorithms to be used with any type of array. > Here's an example: > > foo := GetArray() > result := foo.Take(10).map(...).Sort(...).Reduce(...) > > That is simple to understand and in one line of code. Imagine the > acrobatics (and lines of code) needed to do this using Go's loops! > > You can read my full article on why Go needs generics here: > http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-intelligent-programmers/ > > On Friday, 2 June 2017 09:17:54 UTC+1, Florin Pățan wrote: >> >> Since everyone thinks it but nobody bothers to reply to it: this whole >> thing you propose can be currently done with a for loop, which not only is >> explicit about what it doing, but it also lets you control if you want to >> exit early from it and so on. Complicating the whole language because >> something is cool (yet looks like a really complex thing that you need to >> think about while reading the code) is in no one's benefit. Stop trying to >> avoid a couple of extra rows of for {} (where the third row is literally >> just an "}") and start embracing the fact that you can understand the code >> by looking at it and not apply any complex mental acrobatics to figure out >> what those three lines of code are doing. Your future self/person after you >> will thank you for that. > > -- 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.
