code review 5713049: reflect: make Value.Interface return immutable data

reflect: make Value.Interface return immutable data

Fixes issue 3134.

[rsc, 2012-03-01 06:17:46]

Hello golang-dev@googlegroups.com,

I'd like you to review this change to
https://go.googlecode.com/hg/

[r, 2012-03-01 06:45:32]

LGTM although some documentation might be called for.

[rsc, 2012-03-01 16:42:33]

On Thu, Mar 1, 2012 at 01:45,  <r@golang.org> wrote:
> LGTM although some documentation might be called for.

I'm not sure what to say.  An interface{} is supposed to be like a value,
and now it is.  I tried writing some things but they all sound like
"This does not have a bug.".

Russ

[rsc, 2012-03-01 16:48:29]

*** Submitted as http://code.google.com/p/go/source/detail?r=0e0a2d1892f4 ***

reflect: make Value.Interface return immutable data

Fixes issue 3134.

R=golang-dev, r
CC=golang-dev
http://codereview.appspot.com/5713049

[r2, 2012-03-01 20:43:58]

On Mar 2, 2012, at 3:42 AM, Russ Cox wrote:

> On Thu, Mar 1, 2012 at 01:45,  <r@golang.org> wrote:
>> LGTM although some documentation might be called for.
> 
> I'm not sure what to say.  An interface{} is supposed to be like a value,
> and now it is.  I tried writing some things but they all sound like
> "This does not have a bug.".

the question i would like to see answered is, does the return value from
Interface{} represent the object inside the Value or a copy of the object inside
the Value? the comment

	We need to return a pointer to unchanging data, so make a copy.

does not appear represented in the doc comment for the method.

-rob

[rsc, 2012-03-01 20:48:43]

On Thu, Mar 1, 2012 at 15:44, Rob 'Commander' Pike <r@google.com> wrote:
> the question i would like to see answered is, does the return value from
Interface{} represent the object inside the Value or a copy of the object inside
the Value? the comment
>
>        We need to return a pointer to unchanging data, so make a copy.
>
> does not appear represented in the doc comment for the method.

But an interface{} value is always a value;
it is never an alias for some other value.

It would be like documenting that after

    var i = 2
    var j = i

assigning to i does not change the value of j
(except that here j is an interface{} and there is
some reflection involved).

It is true that at the implementation level there is possible
aliasing that must be accounted for, but at the language
level it's just any other value.  The CL makes them behave
the way the language already requires.

Russ

[r2, 2012-03-01 20:54:42]

On Mar 2, 2012, at 7:48 AM, Russ Cox wrote:

> On Thu, Mar 1, 2012 at 15:44, Rob 'Commander' Pike <r@google.com> wrote:
>> the question i would like to see answered is, does the return value from
Interface{} represent the object inside the Value or a copy of the object inside
the Value? the comment
>> 
>>        We need to return a pointer to unchanging data, so make a copy.
>> 
>> does not appear represented in the doc comment for the method.
> 
> But an interface{} value is always a value;
> it is never an alias for some other value.

but that's exactly the confusion. if i have a Value, i can Set it, but if i have
a Value.Interface(), changing its value does not change the original item. the
doc comment half-implies the opposite behavior, and people have been confused by
that.


> 
> It would be like documenting that after
> 
>    var i = 2
>    var j = i
> 
> assigning to i does not change the value of j
> (except that here j is an interface{} and there is
> some reflection involved).
> 
> It is true that at the implementation level there is possible
> aliasing that must be accounted for, but at the language
> level it's just any other value.  The CL makes them behave
> the way the language already requires.
> 
> Russ

[rsc, 2012-03-01 20:57:22]

> but that's exactly the confusion. if i have a Value, i can Set it, but if i
have a Value.Interface(), changing its value does not change the original item.
the doc comment half-implies the opposite behavior, and people have been
confused by that.

I still don't know what to write.
I thought about:

// Interface returns v's value as an interface{}.
// Future changes to v will not be visible in the returned interface{}.

but I think that will confuse people when v's value is a pointer,
because writes *through* that pointer will be visible, like any
other pointer.

I could do just

// Interface returns v's current value as an interface{}.

[r2, 2012-03-01 21:04:29]

On Mar 2, 2012, at 7:57 AM, Russ Cox wrote:

> // Interface returns v's current value as an interface{}.

better. maybe

// Interface returns v's value as an interface{}. It is equivalent to
//	var result interface{} = (concrete value inside v).

(and make 'result' or whatever be the name of the return value)

that addresses your point that it's doing what Go does and also gives an
operational definition that may be easier to understand.

-rob