But this/your code is not really using generics - it is using interfaces. The only type check is that the instances implement fmt.Stringer - this is very different than the previous version.
> On Jan 1, 2021, at 2:51 PM, da...@suarezhouse.net <da...@suarezhouse.net> > wrote: > > Wow, you are awesome! I think this shows that generics "can be" fully hidden > from view of typical users if desired. In other words, the typical user > wouldn't need to know they exist whereas more advanced users can leverage to > minimize code duplication. My question is: should that be a goal or is it a > non-goal? > > I see what you are saying in terms of might be less readable but if I put > myself in the shoes of someone that has never seen anything about generics > and this example works (which it does), potentially stating it as a goal > would alleviate concerns on losing simplicity? e.g. the library writer can > always make the effort to hide the usage of generics if the intended audience > is the general public vs. internal code while the internal code would still > have the same compile time checks, reduction of duplication, etc. > > Thoughts? > > Thanks again! > David > On Friday, January 1, 2021 at 2:21:15 PM UTC-6 ren...@ix.netcom.com wrote: > I think the first version is far more understandable. You are declaring the > Table and the types for each column - passing the type rather than instances > of the type. > > But here is the corrected code https://go2goplay.golang.org/p/VMFOcI91i4X > <https://go2goplay.golang.org/p/VMFOcI91i4X> > > >> On Jan 1, 2021, at 1:56 PM, da...@suarezhouse.net <http://suarezhouse.net/> >> <da...@suarezhouse.net >> <applewebdata://E9D6939F-CA80-4177-9684-9830AB5C65E0>> wrote: >> > >> I am wondering if this is also something easy for the more experienced folks >> here. >> >> I took the example from Rog: https://go2goplay.golang.org/p/ZUAVncRrmZW >> <https://go2goplay.golang.org/p/ZUAVncRrmZW> >> >> and tried to further "hide" the generics implementation on the library side >> by shifting the type instantiation into a function. Only line 45 is the >> change here (previous line commented right above it for ref + in the library >> side the additional New function): >> New link with the changes here: https://go2goplay.golang.org/p/mnc8yjaREwo >> <https://go2goplay.golang.org/p/mnc8yjaREwo> >> >> It feels functionally equivalent but I am getting an error in line 57 which >> has a generic attempt of the previous user side instantiation. Is this >> possible in a slightly different way? >> >> Thanks again! >> David >> On Friday, January 1, 2021 at 11:50:15 AM UTC-6 Brian Candler wrote: >> If by "generics doc" you mean this one >> <https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md>, >> then note: >> >> "Generic types can have methods. The receiver type of a method must declare >> the same number of type parameters as are declared in the receiver type's >> definition. They are declared without any constraint." >> >> That is, you can't define a method on plain Table, but you can define a >> method on Table[T1, T2, T3] >> >> Without actually looking further into what your code is doing, that implies >> the following change: >> >> func (t *Table[T1, T2, T3]) Add (a, b, c interface{}){ >> row := Row {colA: a, colB: b, colC: c} >> append(t.rows, row) >> } >> >> However that's also not right, because you're ignoring the return value from >> append (for more info read the blog posting on slices >> <https://blog.golang.org/slices>). So: >> >> func (t *Table[T1, T2, T3]) Add (a, b, c interface{}){ >> row := Row {colA: a, colB: b, colC: c} >> t.rows := append(t.rows, row) >> } >> >> The next problem is here: >> >> func (t *Table[T1, T2, T3]) Print (){ >> fmt.Println("table format is: %v, %v, %v", >> reflect.TypeOf(t.colATemplate), reflect.TypeOf(t.colBTemplate), >> reflect.TypeOf(t.colCTemplate)) >> for row := range t.rows { >> fmt.Println("%v, %v, %v", row.colA, row.colB, row.colC) >> } >> } >> >> prog.go2:72:33: row.colA undefined (type int has no field or method colA) >> prog.go2:72:43: row.colB undefined (type int has no field or method colB) >> prog.go2:72:53: row.colC undefined (type int has no field or method colC) >> >> Iterating over a slice with just one receiver variable gives you only the >> index. This needs to be: >> >> func (t *Table[T1, T2, T3]) Print (){ >> fmt.Println("table format is: %v, %v, %v", >> reflect.TypeOf(t.colATemplate), reflect.TypeOf(t.colBTemplate), >> reflect.TypeOf(t.colCTemplate)) >> for _, row := range t.rows { >> fmt.Println("%v, %v, %v", row.colA, row.colB, row.colC) >> } >> } >> >> This then breaks because t.rows is a slice of interface{}, not a slice of >> Row. So I changed it to []Row. Then fixing your Println's to Printf's, >> this gives https://go2goplay.golang.org/p/dAnPU_r0DpM >> <https://go2goplay.golang.org/p/dAnPU_r0DpM> and now it runs. >> >> However, I think this still needs work. There should be no need for >> interface{} in Row; you should use generics for this too, and then your >> Table just needs to be a slice of Row[T1, T2, T3] >> >> On Friday, 1 January 2021 at 15:06:15 UTC da...@suarezhouse.net <> wrote: >> I thought I read the generics doc well but.. :-) Help is appreciated: >> >> I instantiate a generic table example here in line 41: >> https://go2goplay.golang.org/p/SadxA0khqx7 >> <https://go2goplay.golang.org/p/SadxA0khqx7> >> >> Then I use it in lines 42 and 43. >> >> The errors I get are below: >> prog.go2:67:10: cannot use generic type Table[colA, colB, colC fmt.Stringer] >> without instantiation >> prog.go2:72:10: cannot use generic type Table[colA, colB, colC fmt.Stringer] >> without instantiation >> >> I am using the same table. The method belongs to the struct so I would >> think should be considered instantiated and that I wouldn't have to repeat >> in lines 42 and 43 the types. >> >> Is this a bug and it should infer since created in line 41 or what did I >> misunderstand in the doc? >> >> Thanks in advance for the help! >> David >> > >> -- >> 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...@googlegroups.com >> <applewebdata://E9D6939F-CA80-4177-9684-9830AB5C65E0>. > >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/09931d6e-c5e0-4d38-844b-2c3e07d03565n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/09931d6e-c5e0-4d38-844b-2c3e07d03565n%40googlegroups.com?utm_medium=email&utm_source=footer>. > > > -- > 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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/e79f54da-c3d9-468f-84f1-b0194d569b31n%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/e79f54da-c3d9-468f-84f1-b0194d569b31n%40googlegroups.com?utm_medium=email&utm_source=footer>. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/8896B61F-214B-473B-9C18-88A8E9B9B219%40ix.netcom.com.
