still because its a lot of fun, testing reader / writer, https://play.golang.org/p/6TBnlY3h6L
On Saturday, June 3, 2017 at 6:24:31 PM UTC+2, mhh...@gmail.com wrote: > > 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.
