I would argue that is not generics code - the fact that you are type checking in the implementation is a problem, and replicating the logic for “each type”.
You would probably have simpler code just define an interface Value(), and a ComplexValue() and two methods… But even then, you need my proposed []concrete as []interface changes. Generics code should never replicate the iteration or any other logic IMO. Take a look at LinkedList.java (or anything else in the Java collections) - no type checking or casting... > On Sep 10, 2018, at 3:11 PM, Wojciech S. Czarnecki <o...@fairbe.org> wrote: > > As empty criticism is bad, I felt compelled to give a consistent* > counter-proposal. One that can make my "Craftsman wishes" > code from previous post compile and run. > > Draft is available at https://github.com/ohir/gonerics > > Both criticism and applauds are welcome. > > -- > Wojciech S. Czarnecki > << ^oo^ >> OHIR-RIPE > > *(consistent to the extents of one day-off spent on it); > > -- > 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. -- 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.
