Share via

Promocja typu (Visual Basic)

  • Artykuł

Podczas deklarowania elementu programowania w module język Visual Basic promuje jego zakres do przestrzeni nazw zawierającej moduł. Jest to nazywane podwyższeniem poziomu typów.

W poniższym przykładzie przedstawiono definicję szkieletu modułu i dwóch elementów członkowskich tego modułu.

Namespace projNamespace
    Module projModule
        Public Enum basicEnum As Integer
            one = 1
            two = 2
        End Enum
        Public Class innerClass
            Shared Sub numberSub(ByVal firstArg As Integer)
            End Sub
        End Class
    End Module
End Namespace

W programie projModuleelementy programowania zadeklarowane na poziomie modułu są promowane do projNamespaceelementu . W poprzednim przykładzie basicEnum i innerClass są promowane, ale numberSub nie, ponieważ nie są deklarowane na poziomie modułu.

Efekt podwyższania poziomu typu

Efektem podwyższania poziomu typu jest to, że ciąg kwalifikacji nie musi zawierać nazwy modułu. Poniższy przykład wykonuje dwa wywołania procedury w poprzednim przykładzie.

Sub usePromotion()
    projNamespace.projModule.innerClass.numberSub(projNamespace.projModule.basicEnum.one)
    projNamespace.innerClass.numberSub(projNamespace.basicEnum.two)
End Sub

W poprzednim przykładzie pierwsze wywołanie używa pełnych ciągów kwalifikacji. Nie jest to jednak konieczne z powodu podwyższania poziomu typu. Drugie wywołanie uzyskuje również dostęp do elementów członkowskich modułu bez uwzględniania projModule w ciągach kwalifikacji.

Porażka podwyższania poziomu typu

Jeśli przestrzeń nazw ma już element członkowski o tej samej nazwie co element członkowski modułu, podwyższenie poziomu typu zostanie pokonane dla tego elementu członkowskiego modułu. W poniższym przykładzie przedstawiono definicję szkieletu wyliczenia i modułu w tej samej przestrzeni nazw.

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

W poprzednim przykładzie język Visual Basic nie może podwyższyć poziomu klasy abc do thisNameSpace , ponieważ istnieje już wyliczenie o tej samej nazwie na poziomie przestrzeni nazw. Aby uzyskać dostęp, abcSubnależy użyć pełnego ciągu thisNamespace.thisModule.abc.abcSubkwalifikacji . Jednak klasa xyz jest nadal promowana i możesz uzyskać dostęp xyzSub za pomocą krótszego ciągu thisNamespace.xyz.xyzSubkwalifikacji .

Porażka podwyższania poziomu typu dla typów częściowych

Jeśli klasa lub struktura wewnątrz modułu używa częściowego słowa kluczowego, podwyższenie poziomu typu zostanie automatycznie pokonane dla tej klasy lub struktury, niezależnie od tego, czy przestrzeń nazw ma składową o tej samej nazwie. Inne elementy w module nadal kwalifikują się do podwyższenia poziomu typów.

Konsekwencje. Porażka podwyższania poziomu typu częściowej definicji może spowodować nieoczekiwane wyniki, a nawet błędy kompilatora. W poniższym przykładzie przedstawiono szkieletowe częściowe definicje klasy, z których jedna znajduje się wewnątrz modułu.

Namespace sampleNamespace
    Partial Public Class sampleClass
        Public Sub sub1()
        End Sub
    End Class
    Module sampleModule
        Partial Public Class sampleClass
            Public Sub sub2()
            End Sub
        End Class
    End Module
End Namespace

W poprzednim przykładzie deweloper może oczekiwać, że kompilator scali dwa częściowe definicje sampleClass. Jednak kompilator nie uwzględnia podwyższania poziomu dla częściowej definicji wewnątrz sampleModuleelementu . W rezultacie próbuje skompilować dwie oddzielne i odrębne klasy, zarówno nazwane sampleClass , jak i z różnymi ścieżkami kwalifikacji.

Kompilator scala częściowe definicje tylko wtedy, gdy ich w pełni kwalifikowane ścieżki są identyczne.

Zalecenia

Poniższe zalecenia reprezentują dobrą praktykę programową.

  • Unikatowe nazwy. Gdy masz pełną kontrolę nad nazewnictwem elementów programowania, zawsze warto używać unikatowych nazw wszędzie. Identyczne nazwy wymagają dodatkowej kwalifikacji i mogą utrudnić odczytywanie kodu. Mogą również prowadzić do drobnych błędów i nieoczekiwanych wyników.

  • Pełna kwalifikacja. Podczas pracy z modułami i innymi elementami w tej samej przestrzeni nazw najbezpieczniejszym podejściem jest zawsze użycie pełnej kwalifikacji dla wszystkich elementów programowania. Jeśli podwyższenie poziomu typu zostanie pokonane dla elementu członkowskiego modułu i nie kwalifikujesz się do niego w pełni, możesz przypadkowo uzyskać dostęp do innego elementu programowania.

Zobacz też