I honestly don t know.
Seems my example is OK for you,
i really thought it was demonstrative
of some confusion,
seems not.
If i m correct in following your understanding and comparisons,
in those two cases,
x := valueType{}
> x.SetName("yo!")
> fmt.Println(x.Name)
>
> y := &valueType{}
> y.SetName("yo!")
> fmt.Println(y.Name)
>
that the instance (x or y) is pointer or value
does not matter because the receiver is a dictator.
And indeed it behaves so on the play.
I admit i never noticed before...
Whatever,
i did not understand,
its flawed,
i failed to express appropriately,
no idea.
Most people do not
> think if 1+1+1, 1+2, 2+1 and 3 as four *different* things,
> for basically all natural usage these four things are just
> one, the number 3
>
i m a bit chocked, but ok,
i can t find words to convince you that
you mixed results and expression.
That is an error to think those
4 different ways to express the same results
are identical in their form and identical in their result.
Some have identical parameters, ultimately,
they only share the same result.
Its typically a reasoning from mathematics,
btw, just thinking.
On Thursday, May 11, 2017 at 1:08:30 PM UTC+2, Volker Dobler wrote:
>
> On Thursday, 11 May 2017 12:39:18 UTC+2, mhh...@gmail.com wrote:
>>
>>
>> I d only remark about this,
>> > so there are actually just two cases: Method is on pointer receiver or
>> not.
>>
>> From the declarer side,
>> there is indeed only 2 cases,
>> which accounts for 50% of the whole,
>> declaration + consumption,
>> the consumer is still accountable for the remaining
>> 50% of the instance consumption and usage.
>>
>>
> I do not agree. Your "other 50%" are indistinguishable,
> they have no observable difference. Most people do not
> think if 1+1+1, 1+2, 2+1 and 3 as four *different* things,
> for basically all natural usage these four things are just
> one, the number 3. It is the same here:
>
> var p *T
> p.M(), (*p).T, (&(*p)).T and so forth might be formally
> different but they are not.
>
> There a two things. Methods on pointer receivers and
> method on values and it does not matter in reasoning about
> the behaviour of the code on how the method is invoked.
>
> V.
>
>
>
>
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
