I think the original proposition is not to add default implementation for
the methods in an interface. The proposal was just want to add extra
methods to the interface. These methods will not get into the vtable of the
interface. Yes, this can be implemented by package level function, but it
is not as nature as adding methods directly to the interface.
On Wednesday, October 19, 2016 at 12:35:33 PM UTC-7, Viktor Kojouharov
wrote:
>
>
>
> On Wednesday, October 19, 2016 at 10:16:50 PM UTC+3, Jan Mercl wrote:
>>
>> On Wed, Oct 19, 2016 at 8:58 PM Viktor Kojouharov <vkojo...@gmail.com>
>> wrote:
>>
>> > Not really, as this is all hypothetical, it might be implemented in a
>> way so that any type that wants to satisfy an interface with default
>> methods has to at least implement all non-default ones. That is to say,
>> with the above example interface, any and all types will be able to match,
>> since the interface doesn't define any other methods (in a sense, it turns
>> into interface{}). However, if a type wishes to define any method that has
>> a default implementation, it can do so, and that implementation will be
>> used.
>>
>> This can serve as a good answer to the question in the thread title. I
>> mean, hypothetically allowing interface types as method receivers makes
>> things less intuitive to use, more complex to specify, implement and
>> understand to source code reader.
>>
>
> I disagree. I see no evidence nor reason why such a feature would make
> things less intuitive or more complex. On the contrary, handling a feature
> in this way seems quite intuitive.
>
>
>>
>> --
>>
>> -j
>>
>
--
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.
