On Saturday, August 27, 2016 at 3:22:04 AM UTC+8, xiio...@gmail.com wrote:
>
>
>
> On Friday, 26 August 2016 16:32:47 UTC+1, T L wrote:
>>
>>
>>
>> On Thursday, August 25, 2016 at 9:30:01 PM UTC+8, xiio...@gmail.com 
>> wrote:
>>>
>>> I get the original points. Though the current behaviour is in my opinion 
>>> consistent with https://golang.org/ref/spec#Method_declarations 
>>> "[Receiver] must be of the form T or *T (possibly using parentheses) where 
>>> T is a type name" and https://golang.org/ref/spec#Method_sets I can see 
>>> the case for extending methods to include any depth of indirection.
>>>
>>> Though I've never had a use case for methods on **T, it's clear that **T 
>>> 's can have real uses.
>>>
>>> If a language extension was requested, which behaviour would you prefer 
>>> for the method sets
>>>
>>> ie
>>>
>>> ***T has methods of ***T, **T, *T, T
>>> or
>>> ***T has methods of just ***T and **T
>>> ?
>>>
>>
>> They are the same.
>>  
>>
>  
> No they are not the same
>
> Take the examples literally, do not expect recursive additions of method 
> sets.
>
> The language specification https://golang.org/ref/spec states the 
> difference between "methods" and "method sets"
>
> I specifically said "methods", not "method sets" in the example.
>
>
ok, I prefer the first one: ***T has methods of ***T, **T, *T, T.
 

-- 
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.

Reply via email to