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.
> 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?
> 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.
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).
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? This would be possible but
it would be an exception to the normal rules how values
are copied during function invocation. Would such an exception
really make the language easier to understand? And if yes:
We would lose the notion of const-ness and method
invocation on non-addressable values would be limited.
> 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.
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 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.
