Type definition 을 통해 방법의 계승을 간단하게 기억할 수 있습니다 (가능)

2021/02/14 Fri 추가 정정

https://play.golang.org/p/g48hm9MiIXb와 같은 예를 감안하면 이 글의'법칙'은 잘못된 것이다.복잡하다고 생각하더라도 설명서대로 생각해야 한다.
견본서에도 다음과 같은 예가 있다.나는 보통 쓰는 것을 빠뜨렸다.

// The method set of PtrMutex's underlying type *Mutex remains unchanged,
// but the method set of PtrMutex is empty.
type PtrMutex *Mutex

먼저~ 뭐가 귀찮아요?

Go 언어 설명서에는 다음과 같은 기술이 있다.
A defined type may have methods associated with it. It does not inherit any methods bound to the given type, but the method set of an interface type or of elements of a composite type remains unchanged:
defined type은 방법이 있습니다.(Type definition에 정의된) defined type은 오른쪽 유형이 가지고 있는 방법을 계승하는 것이 아닙니다.그러나 인터페이스형 방법집과 합성형 요소가 가지고 있는 방법집은 변화가 없다(즉 새로운 정의의 유형으로 계승된다는 뜻이다).
즉

type NewType OldType

처럼 type definition을 쓰는 경우OldType의 유형은

인터페이스 type에서 이 방법 그룹은 NewType에 계승

struct type에서 그 구성 요소를 구성하는 방법 그룹NewType이 계승

이외에 방법조는 계승할 수 없음

goospecreading 학습회에서는 귀찮은데 왜 이렇게 됐지라는 댓글이 올라왔다.확실히 상술한 상황에서 그 필연성을 잘 모른다.(※ composite type은interface type과struct type 이외에 더 있지만 고려할 필요가 없습니다.)

type definition에서 오른쪽 underlying type의method set을 새 형식으로 상속

하지만 각도를 바꿔 보면 상술한 행동거지는 간단할 것 같다.
포착 방법이란'type definition에서 오른쪽 타입의underlying type의method set이 새로운 타입으로 계승된다'는 것이다.다음은 법칙 및 참조라고 약칭합니다.
다음은 구체적으로 살펴보자.

interface type의 경우

https://play.golang.org/p/Wi6RGzUMXfw

package main

type IA interface {
	Method()
}

type IB IA

// 実装を用意しておく
type T int

func (t T) Method() {}

func main() {
	var t IB = T(0)
	t.Method() // IAのMethod setはIBに引き継がれている
	// これはIAのunderlying typeであるinterface type literalのメソッドセットでもある
}

IB는 type definition으로 제작된 신형입니다.오른쪽 유형은 이 상황IA이다.IA의underlying type은 IA의 유형 선언을 정의한 오른쪽의 유형 소양을 가리킨다

interface {
	Method()
}

.이런 유형의 소양 방법집Method()으로 구성되어 있다.(검증하고자 하는 사람은이쪽 봐주세요.이렇게 하면인터페이스형의 경우'법칙'이 성립되었다는 것을 알 수 있다.

struct type의 경우

https://play.golang.org/p/Tqs5iukBhbk

package main

func main() {
	// x's type is U's underlying type literal
	var x struct {
		S
		T
	}
	x.TMethod()
	x.SMethod() // Uのunderlying typeのメソッドセットを確認した

	var v V
	v.TMethod()
	v.SMethod() // VはUのunderlying typeのメソッドセットを引き継いでいる
}

type S int

func (s S) SMethod() {}

type T int

func (s T) TMethod() {}

type U struct {
	S
	T
}

type V U

이때 V도 U의 underlying type의 struct형 소양의 방법집을 계승하여'법칙'이 성립되었다.

이것 이외의 상황

마지막은 가장 일반적인 상황이다.
https://play.golang.org/p/nJAneGnruTD

package main

type S string

func (s S) Method() {} 
// これはSのメソッドではあってもSのunderlying typeであるstringのメソッドではない

type T S // stringのメソッドセットはemptyであるので何も引き継がない

func main() {
	var t T
	t.Method() // 期待通りコンパイルエラーとなる
}

법칙에 따라 T는 S의 방법집이 아니라 S의 underlying type의 방법집이다.
그러나 S의underrling type은string이기 때문에 그 방법조는 비어 있다.따라서 T는 유형 정의에 따라 어떤 방법집도 계승하지 않는다.이것은 설명서의 기술과 같은 결론이기 때문에 이런 상황에서도 법칙이 성립된다.

총결산

type definition 방법조의 계승에 관해서는 설명서에서 오른쪽의 유형과 그 방법조의 규정을 어떻게 계승하는지 설명하지만, 이 글처럼 underrling type의 방법조를 계승하는지를 고려하면 상황을 고려할 필요가 없다.
type definition에 관한 규격서의 첫 번째 기술을 보았는데, 아래와 같이underlying type이 중점이다.
A type definition creates a new, distinct type with the same underlying type and operations as the given type, and binds an identifier to it.
이것도 합치면 "type definition에서 underling type이 중요합니다!"그렇게 생각하면 왠지 편해질 것 같아.
눈에 띄는 곳이나 신경 쓰이는 곳이 있으면 언제든지 알려주세요.