Wprowadzenie do języka Visual Basic

Język programowania Microsoft® Visual Basic® to język programowania wysokiego poziomu dla programu Microsoft .NET Framework. Mimo że jest przeznaczony do łatwego i łatwego w nauce języka, jest również wystarczająco zaawansowany, aby zaspokoić potrzeby doświadczonych programistów. Język programowania Visual Basic ma składnię podobną do języka angielskiego, która promuje przejrzystość i czytelność kodu języka Visual Basic. Wszędzie tam, gdzie to możliwe, używane są znaczące wyrazy lub frazy zamiast skrótów, akronimów lub znaków specjalnych. Składnia nadmiarowa lub niedostępna jest ogólnie dozwolona, ale nie jest wymagana.

Język programowania Języka Visual Basic może być silnie typizowany lub luźno wpisany. Luźne wpisywanie defersuje znaczną część obciążenia sprawdzania typów, dopóki program nie jest już uruchomiony. Obejmuje to nie tylko sprawdzanie typów konwersji, ale także wywołań metod, co oznacza, że powiązanie wywołania metody można odroczyć do czasu wykonywania. Jest to przydatne podczas tworzenia prototypów lub innych programów, w których szybkość opracowywania jest ważniejsza niż szybkość wykonywania. Język programowania Języka Visual Basic zapewnia również silnie typizowana semantyka, która wykonuje sprawdzanie wszystkich typów w czasie kompilacji i nie zezwala na powiązanie w czasie wykonywania wywołań metod. Gwarantuje to maksymalną wydajność i pomaga zapewnić poprawność konwersji typów. Jest to przydatne podczas tworzenia aplikacji produkcyjnych, w których ważna jest szybkość wykonywania i poprawność wykonywania.

W tym dokumencie opisano język Visual Basic. Ma to być pełny opis języka, a nie samouczek języka lub podręcznik referencyjny użytkownika.

Notacja gramatyki

Ta specyfikacja opisuje dwie gramatyki: gramatykę leksykatyczną i gramatykę składniową. Gramatyka leksykalna definiuje sposób łączenia znaków w tokeny formularzy; gramatyka składniowa definiuje sposób łączenia tokenów w celu utworzenia programów Visual Basic. Istnieje również kilka pomocniczych gramatyki używanych do wstępnego przetwarzania operacji, takich jak kompilacja warunkowa.

Gramatyki w tej specyfikacji są zapisywane w formacie ANTLR — zobacz http://www.antlr.org/.

Przypadek jest nieistotny w programach Visual Basic. Dla uproszczenia wszystkie terminale zostaną podane w standardowej obudowie, ale każda obudowa będzie zgodna z nimi. Terminale, które są drukowalnymi elementami zestawu znaków ASCII, są reprezentowane przez odpowiadające im znaki ASCII. Visual Basic jest również niewrażliwy na szerokość podczas dopasowywania terminali, dzięki czemu znaki Unicode o pełnej szerokości pasują do ich odpowiedników Unicode o połowie szerokości, ale tylko na podstawie całego tokenu. Token nie będzie zgodny, jeśli zawiera mieszane znaki o połowie szerokości i pełnej szerokości.

Podziały wierszy i wcięcie można dodać do czytelności i nie są częścią środowiska produkcyjnego.

Zgodność

Ważną cechą języka programowania jest zgodność między różnymi wersjami języka. Jeśli nowsza wersja języka nie akceptuje tego samego kodu co poprzednia wersja języka lub interpretuje go inaczej niż poprzednia wersja, obciążenie może zostać umieszczone na programisty podczas uaktualniania kodu z jednej wersji języka do innej. W związku z tym zgodność między wersjami musi być zachowana z wyjątkiem sytuacji, gdy korzyści dla konsumentów języków są jasne i przytłaczające.

Poniższe zasady określają zmiany w języku Visual Basic między wersjami. Język terminów używany w tym kontekście odnosi się tylko do aspektów składniowych i semantycznych samego języka Visual Basic i nie zawiera żadnych klas programu .NET Framework uwzględnionych jako część Microsoft.VisualBasic przestrzeni nazw (i przestrzeni nazw podrzędnych). Wszystkie klasy w programie .NET Framework są objęte oddzielnymi zasadami przechowywania wersji i zgodności poza zakresem tego dokumentu.

Rodzaje przerw w zgodności

W idealnym świecie zgodność to 100% między istniejącą wersją języka Visual Basic a wszystkimi przyszłymi wersjami języka Visual Basic. Mogą jednak wystąpić sytuacje, w których potrzeba przerwania zgodności może przeważyć nad kosztem, jaki może nałożyć na programistów. Takie sytuacje są następujące:

• Nowe ostrzeżenia. Wprowadzenie nowego ostrzeżenia nie jest w tym przypadku przerwą w zgodności. Jednak ze względu na to, że wielu deweloperów kompiluje się z włączoną funkcją "traktuj ostrzeżenia jako błędy", podczas wprowadzania ostrzeżeń należy zachować szczególną ostrożność.

• Nowe słowa kluczowe. Wprowadzenie nowych słów kluczowych może być konieczne podczas wprowadzania nowych funkcji językowych. Rozsądne wysiłki zostaną podjęte w celu wybrania słów kluczowych, które minimalizują możliwość kolizji z identyfikatorami użytkowników i używania istniejących słów kluczowych, w których ma to sens. Pomoc zostanie udostępniona w celu uaktualnienia projektów z poprzednich wersji i ucieczki od nowych słów kluczowych.

• Usterki kompilatora. Gdy zachowanie kompilatora jest sprzeczne z udokumentowanym zachowaniem w specyfikacji języka, naprawienie zachowania kompilatora w celu dopasowania do udokumentowanego zachowania może być konieczne.

• Usterka specyfikacji. Gdy kompilator jest zgodny ze specyfikacją języka, ale specyfikacja języka jest wyraźnie nieprawidłowa, zmiana specyfikacji języka i zachowanie kompilatora może być konieczne. Wyrażenie "wyraźnie nie tak" oznacza, że udokumentowane zachowanie jest sprzeczne z tym, czego spodziewa się wyraźna i jednoznaczna większość użytkowników i powoduje wysoce niepożądane zachowanie dla użytkowników.

• Niejednoznaczność specyfikacji. Gdy specyfikacja języka powinna określić, co dzieje się w konkretnej sytuacji, ale nie, a kompilator obsługuje sytuację w sposób niespójny lub wyraźnie nieprawidłowy (przy użyciu tej samej definicji z poprzedniego punktu), wyjaśnienie specyfikacji i poprawianie zachowania kompilatora może być konieczne. Innymi słowy, gdy specyfikacja obejmuje przypadki a, b, d i e, ale pomija wszelkie wzmianki o tym, co dzieje się w przypadku c, a kompilator zachowuje się niepoprawnie w przypadku c, może być konieczne udokumentowanie tego, co dzieje się w przypadku c i zmiana zachowania kompilatora do dopasowania. (Należy pamiętać, że jeśli specyfikacja była niejednoznaczna co do tego, co dzieje się w sytuacji, a kompilator zachowuje się w sposób, który nie jest wyraźnie błędny, zachowanie kompilatora staje się de facto specyfikacją).

• Wprowadzanie błędów czasu wykonywania w błędach czasu kompilacji. W sytuacji, gdy kod ma wartość 100% gwarantuje niepowodzenie w czasie wykonywania (tj. kod użytkownika zawiera jednoznaczną usterkę), może być pożądane dodanie błędu czasu kompilacji, który przechwytuje sytuację.

• Pominięcie specyfikacji. Jeśli specyfikacja języka nie zezwala na konkretną sytuację lub nie zezwala na nie, a kompilator obsługuje sytuację w sposób niepożądany (jeśli zachowanie kompilatora było wyraźnie błędne, byłoby to usterka specyfikacji, a nie pominięcie specyfikacji), może być konieczne wyjaśnienie specyfikacji i zmiana zachowania kompilatora. Oprócz zwykłej analizy wpływu zmiany tego rodzaju są bardziej ograniczone do przypadków, w których wpływ zmiany jest uważany za bardzo minimalny, a korzyści dla deweloperów są bardzo wysokie.

• Nowe funkcje. Ogólnie rzecz biorąc, wprowadzenie nowych funkcji nie powinno zmieniać istniejących części specyfikacji języka ani istniejącego zachowania kompilatora. W sytuacji, gdy wprowadzenie nowej funkcji wymaga zmiany istniejącej specyfikacji języka, taka przerwa w zgodności jest rozsądna tylko wtedy, gdy wpływ byłby bardzo minimalny, a korzyści wynikające z tej funkcji są wysokie.

• Bezpieczeństwo. W sytuacjach nadzwyczajnych obawy dotyczące bezpieczeństwa mogą wymagać przerwania zgodności, takiego jak usunięcie lub zmodyfikowanie funkcji, która jest z natury niezabezpieczona i stanowi wyraźne zagrożenie bezpieczeństwa dla użytkowników.

Następujące sytuacje nie są akceptowalnymi przyczynami wprowadzenia przerw w zgodności:

• Niepożądane lub godne ubolewania zachowanie. Projektowanie języka lub zachowanie kompilatora, które jest uzasadnione, ale uważane za niepożądane lub godne ubolewania z perspektywy czasu nie jest uzasadnieniem niezgodności z poprzednimi wersjami. Zamiast tego należy użyć procesu wycofywania języka opisanego poniżej.

• Czy coś jeszcze. W przeciwnym razie zachowanie kompilatora pozostaje zgodne z poprzednimi wersjami.

Kryteria wpływu

Rozważając, czy przerwa w zgodności może być akceptowalna, kilka kryteriów służy do określenia, jaki może być wpływ zmiany. Im większy wpływ, tym wyższy pasek akceptowania przerw w zgodności.

Kryteria są następujące:

• Jaki jest zakres zmiany? Innymi słowy, ile programów może mieć wpływ? Ilu użytkowników może mieć wpływ? Jak często będzie pisać kod, który ma wpływ na zmianę?

• Czy istnieją jakiekolwiek obejścia, aby uzyskać takie samo zachowanie przed zmianą?

• Jak oczywista jest zmiana? Czy użytkownicy otrzymają natychmiastową opinię, że coś się zmieniło, czy ich programy będą po prostu wykonywane inaczej?

• Czy zmiana może być rozsądnie rozwiązana podczas uaktualniania? Czy można napisać narzędzie, które może znaleźć sytuację, w której zmiana występuje z doskonałą dokładnością i zmienić kod, aby obejść zmianę?

• Jaka jest opinia społeczności na temat zmiany?

Wycofanie języka

Z czasem części języka lub kompilatora mogą stać się przestarzałe. Jak wspomniano wcześniej, nie można przerwać zgodności w celu usunięcia takich przestarzałych funkcji. Zamiast tego należy wykonać następujące czynności:

1. Biorąc pod uwagę funkcję, która istnieje w wersji A programu Visual Studio, opinia musi być żądana od społeczności użytkowników w sprawie wycofania funkcji i pełnego powiadomienia przed podjęciem ostatecznej decyzji o wycofaniu. Proces wycofywania może zostać cofnięty lub porzucony w dowolnym momencie na podstawie opinii społeczności użytkowników.

2. pełna wersja (tj. nie wydanie punktu) B programu Visual Studio musi zostać wydana z ostrzeżeniami kompilatora, które ostrzegają przed przestarzałym użyciem. Ostrzeżenia muszą być domyślnie włączone i można je wyłączyć. Wycofanie musi być jasno udokumentowane w dokumentacji produktu i w Internecie.

3. Pełna wersja C programu Visual Studio musi zostać wydana z ostrzeżeniami kompilatora, których nie można wyłączyć.

4. Pełną wersję D programu Visual Studio należy następnie wydać z przestarzałymi ostrzeżeniami kompilatora przekonwertowanymi na błędy kompilatora. Wydanie D musi nastąpić po zakończeniu fazy wsparcia podstawowego (5 lat od tego zapisu) wydania A.

5. Na koniec może zostać wydana wersja E programu Visual Studio, która usuwa błędy kompilatora.

Zmiany, które nie mogą być obsługiwane w ramach tej struktury wycofywania, nie będą dozwolone.