型の上位変換
更新 : 2007 年 11 月
モジュール内でプログラミング要素を宣言すると、Visual Basic は、そのスコープをモジュールが含まれている名前空間にまで広げます。これを、型の上位変換と呼びます。
モジュールのスケルトン定義およびそのモジュールの 2 つのメンバを、次の例に示します。
Namespace projNamespace
Module projModule
Public Enum basicEnum As Integer
one = 1
two = 2
End Enum
Public Class innerClass
Public Sub numberSub(ByVal firstArg As Integer)
End Sub
End Class
End Module
End Namespace
projModule 内部で、モジュール レベルで宣言されたプログラミング要素は projNamespace に上位変換されます。前の例では、basicEnum および innerClass は上位変換されますが、numberSub はモジュール レベルで宣言されていないため上位変換されません。
型の上位変換による効果
型の上位変換による効果は、修飾文字列にモジュール名を含める必要がなくなるということです。次の例では、前の例のプロシージャに対して 2 つの呼び出しを行っています。
Sub usePromotion()
projNamespace.projModule.innerClass.numberSub(projNamespace.projModule.basicEnum.one)
projNamespace.innerClass.numberSub(projNamespace.basicEnum.two)
End Sub
前の例では、最初の呼び出しで完全な修飾文字列を使用しています。しかし、型の上位変換によりこれは必要ありません。2 番目の呼び出しでもモジュールのメンバにアクセスしていますが、修飾文字列に projModule を含めていません。
型の上位変換の無効化
名前空間に既にモジュール メンバと同じ名前のメンバがある場合、そのモジュール メンバに対する型の上位変換は無効になります。列挙型のスケルトン定義および同じ名前空間内のモジュールを、次の例に示します。
Namespace thisNamespace
Public Enum abc
first = 1
second
End Enum
Module thisModule
Public Class abc
Public Sub abcSub()
End Sub
End Class
Public Class xyz
Public Sub xyzSub()
End Sub
End Class
End Module
End Namespace
この例では、同じ名前の列挙型が名前空間レベルで既に存在するため、Visual Basic は abc クラスを thisNameSpace に上位変換できません。abcSub にアクセスするには、完全な修飾文字列 thisNamespace.thisModule.abc.abcSub を指定する必要があります。しかし、クラス xyz は上位変換されたままなので、短い修飾文字 thisNamespace.xyz.xyzSub を使用して xyzSub にアクセスできます。
部分型に対する型の上位変換の無効化
モジュール内のクラスまたは構造体で Partial (Visual Basic) キーワードが使用されている場合、名前空間に同じ名前のメンバがあるかどうかに関係なく、そのクラスまたは構造体に対する型の上位変換は自動的に無効化されます。モジュール内のその他の要素は、そのまま型の上位変換の対象となります。
結果。 部分定義の型の上位変換の無効化は、予期しない結果、さらにコンパイル エラーを生じさせる可能性があります。クラスのスケルトン部分定義、そのうちの 1 つはモジュール内にある場合を、次の例に示します。
Namespace sampleNamespace
Public Partial Class sampleClass
Public Sub sub1()
End Sub
End Class
Module sampleModule
Public Partial Class sampleClass
Public Sub sub2()
End Sub
End Class
End Module
End Namespace
前の例では、開発者は sampleClass の 2 つの部分定義がコンパイラによってマージされることを想定しています。しかし、コンパイラでは sampleModule 内の部分定義の上位変換は考慮されません。その結果、両方とも名前は sampleClass ですがパスの修飾が異なる、2 つの独立し、区別されたクラスをコンパイルしようとします。
コンパイラは、完全修飾されたパスがまったく同じ場合にのみ、部分定義をマージします。
推奨
プログラミングでは、次の方法に従うことをお勧めします。
一意の名前。 プログラミング要素の名前付けについて完全に制御する場合、どのような場合でも一意の名前を使用することをお勧めします。名前がまったく同じであると余分に修飾する必要があり、コードが読み取りにくくなります。また名前が同じであると軽度のエラーが発生し、予期しない結果が生じる可能性もあります。
完全修飾。 同一の名前空間内でモジュールと他の要素を使用して作業する場合、最も安全な方法はすべてのプログラミング要素に対して常に、完全修飾を使用することです。あるモジュール メンバの上位変換が行われず、そのメンバを完全に修飾しない場合、誤って別のプログラミング要素にアクセスしてしまう可能性があります。