On Mon, 10 Sep 2018 15:31:41 -0500 robert engels <reng...@ix.netcom.com> wrote:
> You would probably have simpler code just define an interface Value(), and > a ComplexValue() and two methods… ...and implement it on any single type I wanna sum? No, thanks. I am doing it already in Go1 :) > But even then, you need my proposed []concrete as []interface changes. But with mine I just have a single generic method to call on any type that fit contract. Contract described in terms of already known types **or its parts**. import "pk" // for generic Sum **method** total := []int.pk.Sum() total += []float32.pk.Sum() total += []Goodie.pk.Sum() total += []Sticker.pk.Sum() > and replicating the logic for “each type”. I do not "replicate logic for each type". I **can** have **a piece** of specialized logic **instantiated** where it has to be different between **classes of types**, i.e. between []int and []complex128. Piece for getting to sum of runes in the utf8 string also need to be different. Adding a four lines to the method you deem not generic will make it suitable for strings. Add to Sum() a single contract clause and 4 lines and suddenly you can do: total += []string.pk.Sum() // if it makes sense in your domain But there is more to that: as I have this distinct piece instantiated for eg complex128 (e.g. as a base type) the **user** of this method can see it immediately. And user whose code will not compile because type does not fit will see the contract in place and can reason why it does not fit with no new (from Go1) concepts. > Generics code should never replicate the iteration or any other logic IMO. I named it "craftsman approach" for a reason :) > Take a look at LinkedList.java (or anything else in the Java collections) - > no type checking or casting... Oh, its only 4 classes depth to read ;) And only 3 brain-years warming up to the java's peculiarities :) >>> java.lang.Object >>> java.util.AbstractCollection<E> >>> java.util.AbstractList<E> >>> java.util.AbstractSequentialList<E> >>> java.util.LinkedList<E> >>> Implemented Interfaces: Serializable, Cloneable, Iterable<E>, >>> Collection<E>, Deque<E>, List<E>, Queue<E> >> Draft is available at https://github.com/ohir/gonerics TC -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- 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.
