I gave you a simple problem, don't over think it. A Set data structure with a simple api that can work out-of-the-box - just as slices and maps with the builtins. I kept the requirements minimal. I'd like to see your solution. On Monday, June 5, 2017 at 12:52:47 AM UTC-4, Egon wrote: > > > > On Monday, 5 June 2017 06:59:46 UTC+3, utyug...@mail.com wrote: >> >> >> >> On Sunday, June 4, 2017 at 12:25:17 PM UTC-4, Egon wrote: >>> >>> I think you are missing the point of my comment. >>> >>> I'm all for generics, but I also can survive without them without much >>> of a problem. (I'm even maintaining >>> https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4 >>> >>> to understand the problem better) >>> >> >> create a custom container type that I can use with any type >> out-of-the-box. >> >> for example: iset := make(Set[int],9); sset := make(Set[string],9); pset >> := make(Set[Person]); >> >> right now, my solution is to rewrite the source with go generate calling >> a tool i wrote which grew out from a great talk from robert griesemer. The >> video: https://www.youtube.com/watch?v=vLxX3yZmw5Q >> >> This solution has nearly twice the performance increase over maps with >> almost every type used so far. Now I could have just written the 500 lines >> of code over and over again for every type needed until the end of time(or >> copy and paste and edit until the end of time), or I could use empty >> interfaces which throws type safety out the window, but I chose to write a >> tool, and when go generate came to be I chose to use that tool like a >> simple script executed within a '//go:generate go run..' tag. >> >> >> Over time golang(I do this now to annoy the zealots) provided the >> tools(reflection, /go packages, go generate) that made creating custom >> generic type safe containers easier. These things weren't always this easy, >> and these things could be easier. >> >> And I am serious about create a custom container type that I can use with >> any type out-of-the-box. Please indulge me, how would you solve this >> problem. Provide a solution for a simple type-safe container type Set that >> takes any type, with a simple api of >> insert,remove,contain,union,difference,intersection, >> complement,superset,subset. >> > > I would use copy-paste. That action to specialize and clean-up API is > pretty trivial, it might take me 3min (probably less), but it isn't a > problem. I often spend more time on tweaking CSS or figuring out what the > customer needs. Copy-pasteing code is annoying, but it's trivial low-effort > work... so it's not a problem. *There of course are probably domains > where this 3min might be a problem*. Then you might use a > reflect/interface based solution and create a type-safe wrapper. Or use > code-generation. > > 3min writing code, isn't a problem for me. > > There's also a subtle problem here, I consider > "insert,remove,contain,union,difference,intersection,complement,superset,subset" > > API somewhat unclear... it loses domain knowledge and may provide more > functions than strictyl necessary... this of course it depends on the > context. > > Also, where will this set be used? Set data-structures have a ton of > different trade-offs. I really don't know how to write a really good > general purpose Set. (see > https://github.com/golang/go/wiki/HowToAsk#the-story-of-a-bad-question) > > I've seen you provide solutions in the past, so I would like to see your >> solution to this not-much-of-a-problem. >> > >> >>> >>> The issue I was trying to highlight was that you are proposing solutions >>> to a problem, but other people don't know what your exact problem is. Hence >>> my 3 lines version are equivalent in their result and value, because the >>> problem is missing. >>> >>> Similarly, when we don't have a concrete problem we could over-engineer >>> the generics or alternatively solve the wrong problems. >>> >>> For example, when the solution you propose only solves 5% of the >>> problems that generics needs to solve... or vice-versa... a generics >>> solution 100x simpler would solve 99% of the cases... then what is the >>> value of the proposed solution? >>> >>> So, which of the 147 different generics approaches/implementations works >>> better for Go and why? (I'm also counting the ones that aren't known yet :D) >>> >>> When you would use a real-world example and problem, it would be >>> possible to argue that one approach is better than the other... without >>> one, this discussion doesn't lead to anywhere. >>> >>> + Egon >>> >>> On Sunday, 4 June 2017 19:09:17 UTC+3, mhh...@gmail.com wrote: >>>> >>>> given the fact that actually everybody disagrees on that idea, >>>> or even something similar according to some feedback. >>>> >>>> I want to put the question differently. >>>> >>>> My mean is to say that golang is a basis to build upon in general that >>>> is better >>>> than other existing solutions. >>>> >>>> imho, golang is governed by its compatibility requirement, >>>> and, an extremely vertical approach, >>>> which blocks every possible update to the dogma: >>>> is it go 1.0 compatible ? >>>> >>>> And because its vertical, is it to my taste ? >>>> >>>> The go 1.0 compatibility requirement makes everybody very happy. >>>> >>>> Still, I dont believe the language is considered as finalized by a >>>> majority of users. >>>> Some will say it misses generics, some other (..) will try different >>>> approach. >>>> >>>> Why should it be that much of frictions ? >>>> >>>> Why can t we evaluate a solution where multiple vision co exists ? >>>> Handle the change. >>>> >>>> Aint there existing case of such kind of symbiosis which benefits each >>>> other on the long term ? >>>> >>>> A solution where the go 1.0 requirement is kept valuable, >>>> and a new language target where this requirement has been removed. >>>> A transpiler to go 1.0 compatible code ? >>>> So both can exist ? >>>> >>>> my 2 cents, >>>> that close and negative answer i got, >>>> is not helpful nor inclusive, >>>> its like take or leave attitude, >>>> >>>> it d just be more inclusive to say that >>>> it is ok to make a transpiler/or whatever it should be/ implementing >>>> your idea, >>>> check that resource for further implementation come back here for >>>> questions. >>>> >>>> Other consideration, >>>> the idea that golang 1.0 is used to build a different language target >>>> that compiles back to go1.0, >>>> looks cool. >>>> >>>> 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.
