回答編集履歴
2
改善
test
CHANGED
@@ -48,7 +48,7 @@
|
|
48
48
|
|
49
49
|
|
50
50
|
|
51
|
-
これではインターフェースと
|
51
|
+
これではインターフェース型と非インターフェース型の互換性チェックがむやみに複雑になるし、
|
52
52
|
|
53
53
|
あとから定義を見直したときにも互換が取れているのかが読み取りにくくなります。
|
54
54
|
|
1
追記
test
CHANGED
@@ -13,3 +13,45 @@
|
|
13
13
|
以上の全てが一致して初めてそのメソッドをサポートしてる扱いになるといのが原則です。
|
14
14
|
|
15
15
|
受け渡しされるものが同じ型かどうかは関係ありません。
|
16
|
+
|
17
|
+
|
18
|
+
|
19
|
+
----追記----
|
20
|
+
|
21
|
+
|
22
|
+
|
23
|
+
挙動自体は把握されてるとのことなので
|
24
|
+
|
25
|
+
あとからこの質問を参照する人のために補足だけ追記しておきます。
|
26
|
+
|
27
|
+
|
28
|
+
|
29
|
+
あくまで「InterfaceA」と「*StructA」は異なる値をもつ型です。
|
30
|
+
|
31
|
+
(前者は値と型を値として格納されており、後者は値のみです)
|
32
|
+
|
33
|
+
ある構造体をあるインターフェースの値に代入する時、互換がある場合は
|
34
|
+
|
35
|
+
暗黙(自動)で型変換されるという機能があるだけです。
|
36
|
+
|
37
|
+
|
38
|
+
|
39
|
+
仮に例示のメソッドの返値の型が「InterfaceA」と「*StructA」のどちらを記述しても
|
40
|
+
|
41
|
+
インターフェースとしての互換性があると判定できるようになっていたとしても思い当たるようなメリットがありません。
|
42
|
+
|
43
|
+
|
44
|
+
|
45
|
+
その判定を行うためには「あくまで異なる型」を一度互換がとれていると仮定して
|
46
|
+
|
47
|
+
互換が取れているのかを確認する必要が出てきます。
|
48
|
+
|
49
|
+
|
50
|
+
|
51
|
+
これではインターフェースと値の互換性チェックがむやみに複雑になるし、
|
52
|
+
|
53
|
+
あとから定義を見直したときにも互換が取れているのかが読み取りにくくなります。
|
54
|
+
|
55
|
+
|
56
|
+
|
57
|
+
なのでインターフェースの互換チェックではメソッドのシグネチャ(メソッド名や入出力パラメータの数や型)が合致するかどうかというシンプルなルールだけで判定されます。
|