Common difficulties with reflection

[Joshua Liebow-Feeser]

Hey all,

I'm planning on giving a talk at an upcoming Go meetup on reflection - how it works and what you can do with it. I'm looking for common difficulties that people have with reflection - not understanding how it works, certain behavior that's confusing, not understanding how to use it, etc. Any ideas/personal experiences?

Thanks!
Cheers,
Josh

[Jesse McNelis]

On Fri, Jan 31, 2014 at 9:46 AM, Joshua Liebow-Feeser <josh...@gmail.com> wrote:

Hey all,

I'm planning on giving a talk at an upcoming Go meetup on reflection - how it works and what you can do with it. I'm looking for common difficulties that people have with reflection - not understanding how it works, certain behavior that's confusing, not understanding how to use it, etc. Any ideas/personal experiences?

A really common difficulty that comes up with newbies is 'how do you get a reflect.Type of an interface value?'

The problem is that if you pass an interface value to reflect.TypeOf() it will get implicitly converted to interface{} and reflect will look at the value inside it.

The solution being to pass a pointer to an interface value instead of the interface value, thus the pointer is wrapped in an interface{} and reflect sees the interface pointer inside it.

--
=====================
http://jessta.id.au

[Donovan Hide]

Remembering to indirect pointers!

http://golang.org/src/pkg/reflect/value.go?s=61277:61305#L2090

--
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/groups/opt_out.

[Brendan Tracey]

Knowing that it's not magic and it doesn't give you generics. I spent a while when I first saw the reflection package trying to figure out how to take an (unknown) interface{} and trying to get it's underlying concrete type without doing a cast.

[roger peppe]

One particular gotcha I've encountered a couple of times
is described in http://golang.org/issue/6231

Specifically reflect.ValueOf(nil) is not assignable
to anything, even if the target value is of interface type.

[Rob Pike]

If people are new to Go, they shouldn't be using reflection at all.

-rob

[Art Mellor]

Perhaps you were just being flippant, but it might be helpful to define "new" in this instance. How does one tell when they are "allowed" to use reflection?

And I'm hoping the answer isn't "when you know how it works" as I think the OP's intent was to help people get there.

- someone who considers himself new to Go who has needed to use reflection and hopes he didn't violate some secret Go rule that will get him ostracized. :-)

[Rob Pike]

Reflection is subtle even for experts. It exposes details whose
understanding depends on knowing pretty fundamental things about how
the language works and, to a lesser extent, how it is implemented. It
can be bewildering even for experienced Go programmers; for newly
minted Gophers there are much more important, simpler things to learn
first. Those who learn reflection too early confuse themselves cloud
their understanding of those fundamentals. Best to keep it at arm's
length until the rest of the picture is clear.

-rob

[Joshua Liebow-Feeser]

This is for a Go meetup, so my expectation is that most of the people there will be relatively experienced. That said, I'm completely on board with the idea that reflection is hard even for experts; it's certainly been by far the feature which has given me the most difficulty, and is one of the few language features which, having programmed in Go for two years now, I wouldn't dream of claiming to really understand.

- josh

[egon]

You might consider rather topic like: "How not to use reflection/inheritance."...

e.g. I wanted to do this with "inheritance" or "reflection", this is what mess I 

ended up with and then show the better version with using interfaces/closures.

It would be probably more beneficial.

Few examples on that topic:

* https://github.com/tobia/fn --> http://play.golang.org/p/orcs3vFMY2

* https://groups.google.com/forum/#!topic/golang-nuts/Hkmyj6tqDWo/DoDDnS3glY8J

If you need to use reflection it's usually worth trying to investigate alternatives;

often the alternatives can be cleaner, type-safer, more fault-tolerant.

If it's hard to write something in Go, it's probably a bad idea to write it that way.

+ egon

[Brendan Tracey]

I hate to see it this way, but I think the answer is "when you encounter a problem which actually needs reflection". There is circular logic there (how do you know when you need it?) but when one has groked interfaces, embedding, and casting, and you know that's not enough (and you're sure you're asking the right question), then it's time to start looking at reflection. 

[egon]

On Saturday, February 1, 2014 10:44:03 AM UTC+2, Brendan Tracey wrote:

I hate to see it this way, but I think the answer is "when you encounter a problem which actually needs reflection". There is circular logic there (how do you know when you need it?) but when one has groked interfaces, embedding, and casting, and you know that's not enough (and you're sure you're asking the right question), then it's time to start looking at reflection. 

I always see it happening reverse. People try to write like they do for other languages...

of course they don't have generics, which means they use reflection to get a similar effect...

which means they skip properly learning the interfaces/embedding/casting and other idioms.

The rule of thumb should be that "you don't need reflection", but when you do, you should

have exhausted all other possibilities (including discussing it in the forums).

Ideally, yes, it wouldn't be backwards... i.e. people learn properly how to use interfaces, 

embedding, casting etc... realistically this doesn't always seem to happen 

with people coming from other languages.

So demonstrating that "you don't need reflection" is useful.

(But, then again I may have some distorted view of the scope of the actual problem.)

+ egon

[Joshua Liebow-Feeser]

I don't agree that it's necessarily always bad to use reflection. I certainly agree that it should be used sparingly, but in cases where you want to give the user more flexibility, you often have to inspect the structure of what they pass you dynamically. The fn package you linked to is a good example of that, as are the encoding/json and fmt packages, to name a few.

[egon]

On Saturday, February 1, 2014 11:19:14 AM UTC+2, Joshua Liebow-Feeser wrote:

I don't agree that it's necessarily always bad to use reflection. I certainly agree that it should be used sparingly, but in cases where you want to give the user more flexibility, you often have to inspect the structure of what they pass you dynamically. The fn package you linked to is a good example of that, as are the encoding/json and fmt packages, to name a few.

I find that the fn package is a bad example... yes, you can do it that way, but http://play.golang.org/p/orcs3vFMY2 is type-safe, simpler and faster.

encoding/json, fmt are indeed good examples of it's usage.

I'm certainly not saying you shouldn't use reflection; I'm saying you should think twice before deciding to use it.

+ egon