On Tuesday, May 9, 2017 at 2:21:52 PM UTC+2, Volker Dobler wrote:
>
> On Tuesday, 9 May 2017 12:30:38 UTC+2, mhh...@gmail.com wrote:
>>
>> in short and put straightly,
>> 1- i think its not appropriate to let us
>> define pointer/non pointer attribute
>> of a type over multiple points in the code.
>> In my experience of a beginner, its a pain that teaches you to always use
>> pointer by default.
>>
>
> Please keep in mind that while "friendly to newcomers/beginner"
> _is_ important it cannot be the main (or even only) goal of a language
> targeting productivity.
>
I don t intend to, did i, i have not noticed, i want not.
I intent to think about it from my pov.
The how a solution might embrace all those cases expresses,
is subject to debate, if any there should be indeed.
>
>
>> 2- The current way to define a type as value/pointer does indeed serves
>> its job, but absolutely nothing more,
>> that is where i feel there are certain lacks.
>>
>
> What more than "serve[...] its job" would you expect from a
> language construct. Go offers two types of methods, those
> defined on value types and those defined on pointer types.
> Both are useful, both server their job. What's wrong here?
>
>
Help me to not copy a pointer value when its inappropriate.
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.
I have read both your thoughts and the doc, i have not found a
>> "useful feature". I respectfully did not.
>> (hope the ability of value/pointer is not the feature you talk about
>> because i don t intend to remove it, and its barely just a feature i think,
>> its critical)
>>
>
> It is useful to have methods on values and it is useful to have
> methods on pointers. Both are useful: Pointer methods make
> mutation possible and value methods provide a notion of
> const-ness which is useful too and value methods can be invoked
> on non-addressable values which is useful too.
> This type of usefulness might not be obvious on first encounter
> with these two types of 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
// 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.
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 ?
>
>
imho, we should not defines the way the type is stored in memory
>> at its declaration, unless it produces useful barriers to mistakes.
>>
>
> I'm not sure I understand: Something like
> type S struct { a int64; b[3]complex128 }
> actually defines storage layout and I think that the ability to control
> is this in Go is a good (and useful thing).
>
>
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
What can i do with `func (x *T)...` i can not do with `func (x T)`,
except checking for T==nil ?
So i think there should be only no-star on receiver.
>>
>
> 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.
This would be possible but
> it would be an exception to the normal rules how values
> are copied during function invocation.
>
Possibly yes.
> Would such an exception
> really make the language easier to understand?
>
digging.
> And if yes:
> We would lose the notion of const-ness and method
> invocation on non-addressable values would be limited.
>
> I think we misunderstood and hope that helps you to find out about it.
or else, hope i can understand your misunderstanding of my questions.
>
>
>> And that to the question "where to store that instances" (use pointer or
>> value?) the answer should be provider only
>> at the instanciation time. (see below i have a tech question about it
>> btw, please)
>>
>> The only feature it disables i can think about is the feature which helps
>> to tell
>> if your receiver is nil/or not.
>> I question this feature and wonder if it was a worthy trade against other
>> possibilities,
>> if one wants to imagine them, obviously.
>>
>>
>> Side Q,
>>
>> Given this program, with an hypothetical Value type with a method Hello
>> without side effects.
>>
>> func main(){
>> x(T{})
>> }
>>
>> func x(T Value){
>> (&T).Hello() // How is this happening ?
>> // Does it escape the variable ahead of time so x become x(T *Value) ?
>> // Or does it take the address of T wherever it is in memory to
>> manipulate it ?
>> // or maybe it does a copy of T to new *T, do the work, copies, then
>> frees it ?
>> }
>>
>
> I have to admit I'm confused and probably do not understand your
> question so forgive me if I'm unable to explain it in detail.
>
> In func x(T Value) {...} the T is a copy of the zero Value{} (typo here in
> your code?) passed from main.
>
yes indeed a typo, sorry. shall read x(Value{})
> T is addressable and &T is it's address. If T has a method
> Hello than *T has also a method Hello. So (&T).Hello() invokes
> Hello on the copy of the zero value created in main.
>
>
> So it would be the second option: "[...] does it take the address
> of T wherever it is in memory to manipulate it ?"
>
> There is not much magic here. Copying happens during invocation of
> function x, not during the method call Hello(). Freeing the memory
> used by T happens during GC: Once x is done T is unreachable and
> will be collected.
>
> You can read the code and spell out what will happen:
>
> func x(T Value)
> Read it like: function x takes a copy of a Value and names this copy T
>
> (&T).Hello()
> Read it like: Take the address of T and invoke the Hello method from
> type *Value. This is the Hello method from type Value as *Value's
> method set contains all methods from Value.
>
I agree with that, but i believe the devil hides in the details,
so i can t confirm a 100%,
also because im afraid there are still some misunderstandings
that might lead to incorrect description of the questions i have,
in the sense of not the right way to look on it,
not in the sense of technically correct according to the spec,
sorry about that,
and thanks again for your attempts!
>
> I hope this helps a bit.
>
> 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.
