How to get underlying value from a reflect.Value in golang after a reflect.Call?

[Giulio De Donato]

Hi all,

I'm trying to save a function in a variable,
then execute it and get the result.

So far so good, I can do it thanks to reflect.Call
but I can not use the result of that function.

How could I use the result of that func as argument for another param?
How could I use the result of that func if is a contructor for struct type?

my code is pretty similar to
https://bitbucket.org/mikespook/golib/src/27c65cdf8a772c737c9f4d14c0099bb82ee7fa35/funcmap/funcmap.go?at=default

There's also a question on  stack that doesn't resolve my problem :(
http://stackoverflow.com/questions/18091562/how-to-get-underlying-value-from-a-reflect-value-in-golang

Surely I'm missing something

thanks a lot.

[Ian Lance Taylor]

On Tue, Feb 11, 2014 at 5:02 AM, Giulio De Donato <liu...@gmail.com> wrote:
>
> I'm trying to save a function in a variable,
> then execute it and get the result.
>
> So far so good, I can do it thanks to reflect.Call
> but I can not use the result of that function.
>
> How could I use the result of that func as argument for another param?
> How could I use the result of that func if is a contructor for struct type?

I'm sorry I don't entirely understand the question. reflect.Call
returns the results of the function call. So you have a list of
reflect.Value's that you can do whatever you want with.

Perhaps rather than pointing to other code that is similar to what you
want, you could write a short snippet of code that tries to do what
you want and point out where it doesn't work.

In particular I don't know what you mean by "a constructor for struct
type."

Ian

[liuggio]

Thanks Ian,

>So you have a list of reflect.Value's that you can do whatever you want with.

That's the problem I don't know how to work with it

I made a snippet here
http://play.golang.org/p/zvm951llg5

--
 __________________liuggio_________________________________
 
  __/|_      We reject kings, presidents and voting.
/o )   \/    We believe in rough consensus
)__ v _/\          and running code  (I.E.T.F. credo)
______________________________________________________________

[Martin Schnabel]

On 02/11/2014 04:37 PM, liuggio wrote:
> Thanks Ian,
>
> >So you have a list of reflect.Value's that you can do whatever you
> want with.
>
> That's the problem I don't know how to work with it
>
> I made a snippet here
> http://play.golang.org/p/zvm951llg5
>

reflect.Value has an Interface method that returns the value as interface{}
http://godoc.org/reflect#Value.Interface

if you have the interface you can assert its type as usual

http://play.golang.org/p/xJyHU6H310

[chris dollin]

On 11 February 2014 15:37, liuggio <liu...@gmail.com> wrote:

>So you have a list of reflect.Value's that you can do whatever you want with.

That's the problem I don't know how to work with it

What do you /want/ to do with it?

I made a snippet here
http://play.golang.org/p/zvm951llg5

Your snippet calls the function NewFuncs and puts all (1) the
return values in `funcs2`. (The error value will always be nil.)

The result is a slice of one empty Funcs map. If you want

to do Funcs operations on it, you're going to have to get

the properly typed value out:

    var f Funcs = funcs2[0].Interface().(Funcs)

Now you have a Funcs-shaped thing to play with again.

Chris

(carefully not asking exactly why you're going round the
reflection houses)

--
Chris "allusive" Dollin

[liuggio]

Thanks a lot!

>Now you have a Funcs-shaped thing to play with again.

That's great,

new goal: cast(convert) without explicitly write the type of the value...
I'm looking now for a function that does something like:

var f Funcs = funcs2[0].Interface().convert(funcs2[0].Type())

 
> (carefully not asking exactly why you're going round the
reflection houses)

:) I understand your concern (as playground just to get familiar with Go),
I'm developing a dependency injection container,
this library should supports decoupling, code maintenance and TDD :)

I'm new to Go and I did not understand why this design pattern is not so popular in this great language.