How to use []interface{} in generic programing

[hui zhang]

check code below, How to use []interface{} in generic programing?

type IReset interface {
   Reset()
}
type Fight struct {
   hp,mp int
}
func (my *Fight) Reset () {
   my.hp = 0
   my.mp = 0
}
func reset1(x IReset){
   x.Reset()
}
func reset(x []IReset) {
   for i := range x {
      x[i].Reset()
   }
}
func  Reset() {
   arr := make([]Fight,1)
   arr[0].hp = 100
   reset1(arr[0])//OK
   reset(arr)// can not use []Fight as []IReset
}

[Justin Israel]

In past answers to similar questions, I have seen the stated answers being that []Fight and []IReset are not the same type, and there is no support for automatically converting from one to the other, and it will not treat the slice of concrete types as the slice of IReset interfaces because of a difference in memory layout.

Basically I think you would need to make([]IReset) and then type assert when setting the fields:   

https://play.golang.org/p/xceK0aoTvQ

Justin

--
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.
For more options, visit https://groups.google.com/d/optout.

[Konstantin Khomoutov]

On Mon, 23 Jan 2017 17:47:48 -0800 (PST)
hui zhang <fastf...@gmail.com> wrote:

> type IReset interface {
> Reset()
> }
> type Fight struct {
> hp,mp int
> }

[...]

> func reset1(x IReset){
> x.Reset()
> }
> func reset(x []IReset) {
> for i := range x {
> x[i].Reset()
> }
> }
> func Reset() {
> arr := make([]Fight,1)
> arr[0].hp = 100
> reset1(arr[0])//OK
> reset(arr)// can not use []Fight as []IReset
> }

That's answered in the FAQ [1].

To explain using your concrete snippet:

* Each value of the Flight type is laid out in memory as two
consecutive integers (in the general case, depending on the types
of fields and your target H/W architecture, there may exist special
"gaps" between your values, and/or at the end of your value;
this is due to so-called "padding" which is needed due to so-called
"data alignment guarantees" -- you can google this stuff).

* On the other hand each value of any interface type in the current
reference implementation is a pair of pointers: one points at the
type descriptor of the real type of the value stored in that
interface value, and another one points to the value itself.

Now consider your two calls.

When you call reset1(), the compiler constructs a value of the
interface type IReset and passes it as the formal parameter x to your
function. When the function returns, that value is discarded.

To make a call to reset() possible, the Go developers would need to
implement _implicit_ conversions of composite types such as yours.

At first glance this would sound as a no-brainer to do, but consider
what would happen if you had a slice of one million elements?

You could read this definitive explanations of how interfaces are
implemented in [2]. Their memory layout was changed (in 1.5 IIRC, to
make certain garbage collector advancements possible) but the essence
of their working did not changed.

1. https://golang.org/doc/faq#convert_slice_of_interface
2. https://research.swtch.com/interfaces