What is reflection defined to be in Go?

[Matthew Holt]

I've been reading about some discussion on whether type assertions or type switches are reflection in Go. I've been looking in the Go documentation but haven't found much, except for The Laws of Reflection, which are:

- Reflection goes from interface value to reflection object.

- Reflection goes from reflection object to interface value.

- To modify a reflection object, the value must be settable.

So does this mean that a reflection object (from the reflect package) must be used in order to be considered reflection? Or is a type assertion considered reflection because it does something the reflect package can do?

[Jsor]

I would assume that someone was using the "reflect" package if they mentioned "reflection." You can certainly make an argument that any type introspection such as type assertions constitute "reflection" in a technical sense, but regardless of whether you think that's right or not, I think it's confusing to refer to it as "reflection" when the reflect package isn't involved.

[Andrew Gerrand]

On 28 May 2014 12:40, Matthew Holt <matthe...@gmail.com> wrote:

So does this mean that a reflection object (from the reflect package) must be used in order to be considered reflection? Or is a type assertion considered reflection because it does something the reflect package can do?

I would not consider type assertions or type switches to be reflection. So, by that definition, the language itself does not provide reflection. For that you should use the reflect package.

But this is a pretty thin semantic argument.

Andrew

[Peter Waller]

On 28 May 2014 03:40, Matthew Holt <matthe...@gmail.com> wrote:

So does this mean that a reflection object (from the reflect package) must be used in order to be considered reflection? Or is a type assertion considered reflection because it does something the reflect package can do?

Generally speaking, I've usually seen "reflection" used to mean "to programmatically look deep inside the object at runtime", i.e, programmatically inspect or manipulate an object, such as its members, without the library which is using reflection necessarily needing to know what it is manipulating at compile time, for example.

In this sense I wouldn't necessarily consider a type assertion or type switch "reflection", though it is a capability that a reflection library might provide.

You could perhaps say that the go language is "runtime type-aware, through type assertions and switches", and "provides a built-in package for providing runtime reflection".

[Jesse McNelis]

On Wed, May 28, 2014 at 12:40 PM, Matthew Holt <matthe...@gmail.com> wrote:
> I've been reading about some discussion on whether type assertions or type
> switches are reflection in Go.

type assertions in Go are as much 'reflection' as 'instanceof' is in Java.
Generally 'reflection' is anything that allows a running process to
ask questions about the program it's running.
But, mostly when people talk about reflection specifically they are
referring to the cost.
The reflect package can be quite expensive to call. type assertions
are very cheap in comparison.

[Konstantin Kulikov]

Type assertion only applies to interfaces. Interface value contains both type and a pointer to some other value. That is, as much as you doesn't name dereferencing a pointer reflection, type asserion isn't.

[Kevin Gillette]

On Tuesday, May 27, 2014 10:44:59 PM UTC-6, Andrew Gerrand wrote:

I would not consider type assertions or type switches to be reflection. So, by that definition, the language itself does not provide reflection. For that you should use the reflect package.

At the very least, type assertions/switches are runtime type inspection, which the reflect package also must do. 

On Wednesday, May 28, 2014 8:48:36 AM UTC-6, Konstantin Kulikov wrote:

Type assertion only applies to interfaces. Interface value contains both type and a pointer to some other value. That is, as much as you doesn't name dereferencing a pointer reflection, type asserion isn't.

type assertion deals with value in the interface. Also, the reflect package functions aren't generic -- they take interface{}, not some ephemeral T, so type assertions in this way can't be distinguished from the reflect package.

[Rob Pike]

Why does any of this matter?

-rob

[Konstantin Kulikov]

type assertion deals with value in the interface

Dereferencing a pointer is an operation with value as well

 Also, the reflect package functions aren't generic -- they take interface{}, not some ephemeral T

reflect operates on reflect.Value not interface{} 

[Konstantin Kulikov]

Some time ago a read that I shouldn't use reflect package, because it's complex, slow, easy to overuse, etc.

And I also thought that type assertion is part of reflection (it looks similar) when in fact it doesn't have any reflection downsides.

[Kevin Gillette]

On Wednesday, May 28, 2014 3:56:12 PM UTC-6, Konstantin Kulikov wrote: 

Dereferencing a pointer is an operation with value as well

Though pointers, along with slices, maps, channels, and so on "contain" values who's type properties are always known at compile time. Interface values do not meet this criterion.

  

reflect operates on reflect.Value not interface{} 

but you can't obtain a reflect.Value or a reflect.Type without first passing a value in through an interface{} parameter.

[Matthew Holt]

It doesn't really. But this conversation, coupled with research and experimentation, has helped me to understand reflection and certain language features better.