[ generics ] Concrete example of comparables and generic function types

[Beka Westberg]

Hello! I just ran into a problem that is solved really nicely with the new generics proposal and I thought someone might find it interesting :D

I was trying to implement a library for doing ascii art programmatically. The main struct is basically an image.Image except it works with bytes instead of colors. As such you /should/ be able to create functions (like a flood fill algorithm) that are abstracted over both of these types, but without "generics" this cannot be done (with compile time type safety).

I sketched a little project in the go2go playground that implements generic functions for doing Porter-Duff compositions on any types that fulfill the following constraint:

```

type Rect(type T comparable) interface {

At(x, y int) T

Set(x, y int, t T)

}

```

Type defs on lines [8, 13]. Porter-Duff implementation [15, 99] Main [101, 108] ByteImg implementation [110, 185]

I liked this example because it requires passing a generic function (the Porter-Duff func) to another generic function (Merge) :D I hope someone else finds it interesting as well!

--Beka

[Ian Lance Taylor]

Thanks for the example.

Ian

[roger peppe]

Nice example! Presumably if you wanted to do actual Porter-Duff though, you'd want some arithmetic rather than just comparison.

One observation: you don't actually need the "comparable" constraint on many of the core entities there (e.g. Rect and Op) because they don't actually use any compare operations. The code works just fine if you omit them: https://go2goplay.golang.org/p/dKGOaN_v3He

Technically, the "z" argument to Op isn't necessary either AFAICS - you could just use a zero value instead (unless you actually want to be able to have a non-zero "zero" value, I guess).

  cheers,

    rog.

--
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/dbc90697-e276-437b-ab39-b52564fc6d5an%40googlegroups.com.

[Beka Westberg]

> Thanks for the example.

My pleasure :D Thank you for taking a look!

> Nice example! Presumably if you wanted to do actual Porter-Duff though, you'd want some arithmetic rather than just comparison.

Thank you! And yeah if you wanted to do something like a color-dodge or other blend modes you'd definitely need more operations =)

> One observation: you don't actually need the "comparable" constraint on many of the core entities there (e.g. Rect and Op) because they don't actually use any compare operations. The code works just fine if you omit them: https://go2goplay.golang.org/p/dKGOaN_v3He

Good point! All Merge requires is that it accepts and returns the given type, no need to force anything to be comparable at that level :D

> Technically, the "z" argument to Op isn't necessary either AFAICS - you could just use a zero value instead (unless you actually want to be able to have a non-zero "zero" value, I guess).

Yeah in this example it's not needed because you just pass 0 hehe, but I wanted to include it because you can make some pretty cool combinations if you change it. Here's a little example.

But thinking about it... really there's no reason Merge should be passing the zero value around. It's perfectly reasonable to have an Op function that doesn't require one. For example an averaging function. It probably makes more sense to wrap the functions that do require zero values in a closure, as in this example. (I know some of those functions don't require z values, but I wanted them to have a uniform type :D)

Thank you for your feedback!

--Beka