yeah i totally admit i don t master the subject at all,
and i would prefer not have to talk about heap/stack thing,
by incidence what, still, bugs me is on the intersection
of many topics which make it difficult to talk about.
thanks again for your attempts even though i lost you
and, i guess, hurt your love for English grammar,
if you have any.
in this
//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 ?
(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 ?
> 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.
?
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 ?
if not, no worries, i ll learn more and try again later.
On Saturday, May 6, 2017 at 9:39:56 AM UTC+2, mhh...@gmail.com wrote:
>
> Hi,
>
> Question about the receiver of a func.
>
> It can be defined as star/no star, and consumed as star/nostar.
>
> The understanding i have so far is,
> it let the developer define the memory model he d like to use.
>
> It leads to cases such as
> - define start/nostar on a type
> - consume a stared type as a value
> - consume a value type as a pointer
>
> Which is quiet confusing for beginners, and me.
>
> While i understand that someone would like to declare
> a type is consumed by value, I do not understand the last two cases.
> when why they might happen.
>
> Can you explain their value added ?
>
> Thinking further more,
>
> Not speaking about dereferencing a pointer,
> but initialization of a type in a way that is undesired to the provider.
>
> The way a type is consumed by value or reference,
> is an act of design rules (i add a property on the type that make sure it
> is never copied/referenced)
> or an act of consumption,
> the designer did not enforce any rule on the type, i might initialize it
> as star/nostar at convenience.
>
> The fact it is let possible today
> - to not enforce the way a type is manipulated,
> leads to confusion and error (famous one is https://godoc.org/sync)
> - to define at both declaration / usage the star/nostar,
> is confusing, again
>
> so yeah, wondering quiet a lot about that,
> and given the fact i do not understand few use cases,
> i think this could be better handled.
>
> For example,
>
> if a new keyword appear to ensure a type is
> consumed by value, that might be helpful to provide
> a function to make sure that type won t exceed the stack size
> and escape to the heap.
> that keyword would help api designer to avoid consumption problems.
> nop ?
>
> If a new keyword would appear to ensure a type is initialized by reference,
> might help to detect value copy and warn/error when that case is met.
> That would helped consumers to avoid problems.
> nop ?
>
> If the receiver type was not able to be star/nostar,
> that d probably help to get ride of confusion,
> nop ?
>
--
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.
