I’m sorry, but I don’t think your reasoning is correct. See the code below.
Less lines, and better functionality & design, and you can do this today…
(trivial to also add the ComplexPrice)
Although I think you should be able to write:
ip := Prices{1,2,3}
and the compiler could figure out that each should be a IntPrice since that is
the most exact signature - simple enhancement anyone ???
Anyway, here is the working example - and notice there is only a single Sum()
implementation !
type Priceable interface {
GetPrice() int
}
type IntPrice int
type FloatPrice float32
type DiscountPrice struct {
price int
discount int
}
func (ip IntPrice) GetPrice() int {
return int(ip)
}
func (fp FloatPrice) GetPrice() int {
return int(fp)
}
func (dp DiscountPrice) GetPrice() int {
return int(dp.price*dp.discount/100)
}
type Prices []Priceable
func (p Prices) Sum() int {
sum:=0
for _,p := range p {
sum+=p.GetPrice()
}
return sum
}
func TestPrice(t *testing.T) {
ip := Prices{IntPrice(1),IntPrice(2)}
fp := Prices{FloatPrice(1.0),FloatPrice(2.0)}
dp := Prices{DiscountPrice{10,80},DiscountPrice{10,75}}
mix := Prices{IntPrice(1),FloatPrice(2),DiscountPrice{10,80}}
fmt.Println("The total price ",ip.Sum())
fmt.Println("The total price ",fp.Sum())
fmt.Println("The total price ",dp.Sum())
fmt.Println("The total price ",mix.Sum())
}
> On Sep 11, 2018, at 1:38 AM, Wojciech S. Czarnecki <o...@fairbe.org> wrote:
>
> 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.
