I must admit you lost me.
Thus just some minor notes:
On Tuesday, 9 May 2017 16:05:16 UTC+2, mhh...@gmail.com wrote:
>
>
> Help me to not copy a pointer value when its inappropriate.
>
Copying a pointer value is one of the most trivial and fast operations
imaginable.
Maybe you are using the term "pointer value" in some non-standard way here?
> If there s a purpose at defining star/nostar on a type,
> but not mix them either,
> help me to make that happen with ease, rather than pain.
>
> That is, i agree there s point in defining star/nostar like property on a
> type,
> (note i don t speak of receiver at purpose), see below.
>
Maybe this is part of the confusion. The current language (as opposed
to some other hypothetical language, probably better discussed on
some other mailing list) has no star or nostar properties on types.
Some types carry methods. Some don't. Some types are intimately
related like *T and T and share methods.
> yes. The consumer can decide how to consume the value,
> according if its provided/defined type is star/nostar.
>
> //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.
>
> // provided
> //func (r Value) n(x T) {(&x).Hello()} // x passed from stack (there might
> be some magic here, not the point, i think)
> //func (r Value) n(x *T) {(*x).Hello()} // always get x from heap
> //func (r Value) n(x InterfaceDef){x.Hello()} // x is pointer to value
> that matches intf.
>
None of these explanations are accurate.
>
> Why does it matter that the declarer knows about this in its receiver ?
> I can t find much examples about that, besides testing if the receiver is
> nil.
>
> That the declarer defines a type to be handled by copy
> needs proper out values,
> not only nostar def on the receiver,
> does it ?
>
I'm sorry, I do not understand what you are asking.
>
> yes, i m really focused about the receiver.
>
> by incidence i come to think about the struct, indeed somehow,
>
> type S ref { a int64; b[3]complex128 } // prevent copy of S
> type S value { a int64; b[3]complex128 } // prevent referencing to S
> type S struct { a int64; b[3]complex128 } // does not matter
>
It would be helpful if you would define what you mean exactly
when you say "prevent copy" or "prevent referencing" as "referencing"
is pretty vague. How would a=b work if b was of "prevent copy" type?
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
>> A "non-star" receiver would be a method on a value
>> (non-pointer, non-interface) type.
>> This would basically disallow methods to mutate the receiver
>> state as only a copy of the receiver would be mutated.
>> Are you proposing that methods on values should not
>> operate on a copy of the value?
>>
>
> The consumer can tell about it.
>
> If he receives a value `func (x T)` he can say `x.Hello()` or
> `(&x).Hello()`
> If he receives a pointer `func (x *T)` he can say `x.Hello()` or
> `(*x).Hello()`
>
> if he defines `var x T` and do `(&x).Hello()` is weird.
> if he defines `var x *T` and do `(*x).Hello()` is weird.
>
>
Again: I have to admit I'm lost and have no idea what you
try to express.
Regards
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.
