vb.netcom对象 vb属性窗口怎么打开( 七 )


语言本身的变化要远远超过体系结构的变化 。大部分改变确有道理,但我并不认为
所有的改变都是如此 。以前版本的VB允许你以很多方法来做很多事,以至于统一的编码
标准要么不存在要么就很难强加于人 。Microsoft对VB做了大量的改变为的就是“清晰”
这种语言 。很多情况下,原来你有好几种方法做一件事,现在就只有一种了 。Billy Ho
llis 提供了语法变化的详细列表,包括废弃的关键字列表,但有些东西需要在这里重复
一下 。
首先,向过程参数传递数据的默认方法由引用(ByRef)变成了传值(ByVal) 。这个改
变主要是因为引用要比传值的风险大得多 。它的风险主要是调用过程中的数据可能被无
意中篡改 。你仍然能通过引用传递数据,但这一改变使你需要修改新的默认调用方法来
使用引用 。
Set语句消失了
其次 , Set 语句消失了 。在 VB.NET 里如果你需要向变量传递一个对象引用 , 所需
要的只是一个等号,对象被视为同其它值一样 。这很酷,但也有副作用:默认属性消失
了 。例如,你不再能用这种方式引用一个属性:
Text1 = "What, me worry?"
作为替代,你必须显式地引用属性:
Text1.Text = "What, me worry?"
也许一眼看来不需要这种改变,但确实必须去掉默认属性 。例如 , 假定你有一个叫
objFoo的对象变量,不用Set语句 , 下面的语句所设置的引用就产生了歧义性:
objFoo = Text1
这条语句是应该设置到Text1的引用 , 还是以Text1的Text属性来填充objFoo?你不
能确定,编译器也不能 。抛弃Set语句同时要求抛弃默认属性 。
有一个改变我不喜欢:你不再能在不同的作用域里声明Property Get和Property S
et过程 。注意 VB.NET 没有 Property Let 语句:对象和数值都用 Property Set 。这意
味着你不能用一个 Friend Property Let 过程来对应一个 Public Property Get 。用V
B建立组件时可能会有麻烦 。许多组件开发者创建 Friend Property Set 过程以使他们
的应用程序能改变一个值,但提供 Public Property Get 过程以使他们的客户程序能取
回值 。我希望我能为这个改变找到一个合适的理由,可是我找不到 。
Microsoft说它力图使语言保持清晰并使之现代化—大部分情况下它做得不错—但这
个作用域问题和其它几个问题令人感到困惑 。例如 , While...Wend 很早以前就应该消失
了,因为 Do...Loop 完成同样的功能 。然而,Microsoft 不仅没能去掉 While...Wend
,还把它改成了 While...End While 来给自己找了更多的麻烦 。真奇怪!
我最不喜欢的改变是:Microsoft改变了你已经使用的数据类型含义 。在 .NET 里,
Integer 现在是 32 位,而 Long 变成了 64 位 。我心存恐惧地想:开发者 (包括我自
己) 会多么频繁地使用错误的变量啊 。那个API到底是接受一个16位的 Integer还是32位
的?老天!我希望Microsoft重新考虑这个决定并使用新的变量类型 , 比如Int32和Long
64 。无论迁移到 VB.NET的移植工具是多么的好,它也不能改变开发者的记忆 。为什么要
逼着我们再学一遍普通的数据类型呢?
最后 , 最需要的一个改变是:VB.NET引入了 Option Strict 关键字,你可以使用它
来代替 Option Explicit 。Option Strict 结束了万恶的类型强制(tm),通过它VB乐于
让你把一个数值赋值给一个字符串,然后像犯罪一样做另一个操作 。设置 Option Stri
ct 告诉 Visual Basic.NET 不要为你做任何类型强制 。注意 VB.NET 并不是彻底的控制

推荐阅读