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 > > On Jan 1, 2021, at 1:56 PM, da...@suarezhouse.net <da...@suarezhouse.net> > 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 > > 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 > > 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 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 >>> >>> 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. > > 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/e79f54da-c3d9-468f-84f1-b0194d569b31n%40googlegroups.com.
