for the fun, with early return, https://play.golang.org/p/I9AORKOYQm
On Saturday, June 3, 2017 at 12:34:15 PM UTC+2, mhh...@gmail.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: > > 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.
