(я никогда раньше не использовал VB, так что для меня это тоже ново)
Они имеют в виду оператор Option Strict , или, скорее, то, что происходит, когда вы его опускаете.
Следующий VB компилирует и запускает perfeclty до тех пор, пока у вас отключено Option Explicit
:
Class Widget
Sub Method1()
End Sub
End Class
Sub Main()
Dim someInt As Integer
Dim someDouble As Double
Dim someObj As Object = New Widget
someDouble = 1234567890.9876542
someInt = someDouble
Call someObj.Method1()
Call someObj.Method2() ' causes runtime error
End Sub
Вышеприведенное неявно приводит значение типа double к целому числу, вызывает метод Method1
для ссылки Object
и даже вызывает метод Method2
(которого даже не существует) - ни один из которых не скомпилируется в C # или в VB с Option Strict On
.
Это определенно соответствует определению «не как строго типизированный » как C #, хотя термин кажется довольно субъективным.
Обновление: Мы можем использовать ILSpy , чтобы раскрыть "магию", происходящую здесь, глядя на скомпилированную сборку (в C #):
object obj = new Module1.Widget();
double num = 1234567890.9876542;
int i = Math.Round(num);
NewLateBinding.LateCall(obj, null, "Method1", new object[0], null, null, null, true);
NewLateBinding.LateCall(obj, null, "Method2", new object[0], null, null, null, true);
Это объясняет, почему компилятор VB.Net способен делать вещи, которые в противном случае кажутся недопустимыми в CLR, хотя, похоже, он приводит к некоторому снижению производительности во время выполнения.