Sorry, the code works as expected - as I thinking of something else. > On Jan 1, 2021, at 3:49 PM, robert engels <reng...@ix.netcom.com> wrote: > > 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 <http://suarezhouse.net/> >> <da...@suarezhouse.net <mailto: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 >> <http://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://4F94DAA5-329D-4524-8B14-3F201C205EA4>> 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://4F94DAA5-329D-4524-8B14-3F201C205EA4>. >> >>> 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/BA3A987D-8B5A-401F-B3AE-05C09D42DCCB%40ix.netcom.com.
