On Thursday, 11 May 2017 11:28:33 UTC+2, mhh...@gmail.com wrote:
>
> //defined
>> var x &T{} // put on heap
>> var x T // put on stack
>>
>> This is definitely a misconception: Allocation on heap vs stack is
>> totaly unrelated to value methods vs pointer methods. Both examples
>> might be allocated on the stack or on the heap and this depends
>> on other factors than methods of T.
>>
>
> what are other factors ?
>
Roughly: If the compiler cannot prove that x *can* be safely put on the
stack then it must go to the heap. Values cannot go safely to the stack
if they might outlive the scope of this stack frame / the current function.
This can happen if e.g. a pointer to such value leaves the function, e.g.
in a return or a channel send. Search for escape analysis if you are
interested in the gory details, but I'd urge you not to until the basic
stuff
is total clear.
> (let s keep it short, optimized code is not a topic for me)
> I understood that the next func call (might be method)
> will decide how the instance (to not say value here) is passed.
>
> is it ?
>
Each and every function --- be it a normal function, a function literal,
a closure, a method, whatever --- completely determines its arguments.
This includes the receiver of a method which technical is just a normal
(the first) function argument.
A func f(int) is called with an argument of type int and a func g(*int) is
called with a *int. The same is true for receivers. There is *no* magic
here!
The only thing "magical" with methods and their special receiver
argument that the compiler automatically (automagically) takes the
address of a value or dereferences a pointer to match the method
signature. That's all. That's convenience only. A bit less typing, a bit
fewer braces, it reads nicer.
So: Yes, it is.
>
>> What can i do with `func (x *T)...` i can not do with `func (x T)`,
>>> except checking for T==nil ?
>>>
>>
>> Like explained several times in this thread:
>> func (x *T) lets you modify *x
>>
>
> yes, i really want not to question
> the ability to modify a value in place.
>
> its really about its form.
>
> In this code,
> starting at 0,
> is case 1 not an aberration,
> is case 3 is useless
> https://play.golang.org/p/VyOfZyt7rw
>
> Note case 0 is expected to fail and might be detected.
>
> ?
>
All four cases a perfectly fine and useful.
The problem here is *not* the language construct but probably
your prejudice that a method called "SetName" should
modify the x it is "applied" to in any case as it does e.g.
in Java where there are no (non-primitive) value types.
Let's use abstract function names and let's add some real
code (as setters and getter in Go are a bit funny).
type T { s string }
func (t T) M(s string) {
if t.s == "" { t.s = "GET" } // default HTTP method used if nothing else
selected
foo(t, s)
}
default := T{}
default.M("bar")
post := T{s: "POST"}
post.M("bar")
Can you see it? M operates on a copy of the value it is invoked
on. Both default and post will be copied. The copy of default is
modified and this modification is passed foo. This is nice and
useful and there is no reason the disallow this type of code.
It is really dead simple: If your methods intend to modify the receiver,
the receiver must be a pointer. This is one simple rule, clear and
straightforward, easy to remember and easy to derive in case one
forgets it.
Again. This all does not depend on what the x in x.M is. it can
be a pointer or a value, the compiler will take the address or dereference
as needed, so there are actually just two cases: Method is on
pointer receiver or not. As I said. Dead simple.
>
> Probably i miss some understanding about why i can do that,
> - handle value handling in two places of the program
> - at initialization, at consumption
>
> does it help ?
>
I'm sorry I do not understand the question.
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.
