Insider's EyeVisual Basic 2005はVBユーザーを救えるか?― Visual Basic 6.0のメインストリーム・サポート終了の影響度 ―― Greg DeMichillie2004/09/04 Copyright (C) 2004, Redmond Communications Inc. and Mediaselect Inc. |
|
Page1
Page2
|
本記事は、(株)メディアセレクトが発行する月刊誌『Directions on Microsoft日本語版』 2004年9月15日号 p.18の「Visual Basic 2005はVBユーザーを救えるか?」を、許可を得て転載したものです。同誌に関する詳しい情報は、本記事の最後に掲載しています。 |
2005年3月にVisual Basic 6.0のサポートがメインストリームから延長サポートへ移行するとともに、.NET Frameworkの一部にリプレイスされた広範な技術のメインストリーム・サポートも終了する。それは既存アプリケーションが直ちに利用できなくなることを意味するものではないが、IT部門は、どの技術が将来的にフェーズアウトし、どのような技術が後継として登場するのか理解しておかなければならない。またVisual Studio 2005は、VB開発者が.NET移行で直面するさまざまな問題を解決しており、同製品の登場はIT部門にとってVB開発を再検討する絶好の機会でもある。
■
Visual Basic(以下、VB)はMicrosoftが提供する最もポピュラーなプログラミング製品であり、恐らくほかのベンダのいかなるプログラミング言語より幅広く利用されている。基本的にVBは、データベースに接続するシック・クライアント・ユーザー・インターフェイスを構築するツールとして、独占的ポジションを獲得した。VBクライアントには、スタンドアロン・アプリケーションと、OfficeのVisual Basic for Applications(VBA)で作成されたOfficeアプリケーションのカスタム・アドオンがある。
過去との決別
Microsoftは以前もVBの古いバージョンのサポートを中止したことがあり、1999年1月にリリースされたVB 6.0のサポートが中止されたとしても驚くには当たらない。ただし、これまでの場合、VBの最新バージョンは旧バージョンで構築されたアプリケーションを保守するために利用できた。
今回の移行は、その点で異なる。VB 6の後継となるVisual Basic .NET(以下、VB.NET)は、過去のバージョンと技術的な断絶がある。VB.NETは旧来のほとんどの開発者APIを新しい.NET APIにリプレイスしており、.NET以前のアプリケーションの保守には利用できない。プログラミング言語やベース・ライブリラリなど、VBプラットフォームの主要なAPIとコンポーネントには、大幅な変更が加えられている。
これらがどのように変更されたかについては、以下の「Visual Basicディベロッパ・スタック」を参照。
Visual Basicディベロッパ・スタック
VB 6は.NETへ移行する前のクラシックVBの最後の段階だ。ここではVB開発者に提供されている重要なAPIを表にまとめた。クラシックVBに含まれるAPIのほとんどは、VB.NET移行でリプレイスされ、開発者には衝撃的な変更だった。対照的に、VB.NET、VB 2003、VB 2005の間の変更は比較的穏やかだ。いくつかの変更があっても、それ以前のような根本的なアーキテクチャの再構築はない。
|
言語とベース・ライブラリの進化
VBプログラミング言語のルーツはBASICだが、ユーザーがホビー使用からITプロフェッショナルへとシフトするとともに、長年にわたって機能拡張されてきた。
●矛盾に悩まされたクラシックVB
VB 6.0以前のクラシックVB言語はBASIC上に構築されたが、プロパティやイベントとともに、オブジェクトを利用するためのサポートなど、オリジナルにはないさまざまな言語機能が追加された。ところが、次々に新しい機能が追加される一方、VBは時代遅れとなった言語機能も旧バージョンから数多く継承した。そのため既存のコードを継続して利用することができ、従来のVB開発者にとっては便利だったが、反面、新しいVB開発者たちはさまざまな矛盾と重複に悩まされることになった。
こうした問題の1つの例は、キーワードのletとsetの違いだ。いずれも変数に値を割り当てるときに用いられるが、一定の条件では互換性があり、別の条件ではまったく異なる副次的効果をもたらす。
VBはまた、文字列の操作やファイルの読み書きといったタスクに一連のAPIセットを含む。技術的にはVBプログラミング言語の一部ではないが、これらのAPIはVB開発環境の重要なパーツだった。
●VB.NETでの大幅な改良
クラシックVBは2001年、VB.NETにリプレイスされた。VBの歴史上、最も大幅な変更が行われたのがこのときだ。VB.NETでは、完全なオブジェクト指向プログラミングのサポートなど、メジャーな言語機能の追加に加え、長年蓄積されてきたさまざまな冗長性や重複機能が排除された。しかし、こうした大掛かりな改良によって、VB.NETは既存のVBコードに対する下位互換性を欠くものとなった。そうした反省から、VBの将来バージョンではVB.NET言語との互換性に重点が置かれることになるだろう。従って今日、VB.NETで記述したコードは、たとえVB.NETツールが退役した後でも、問題なく動作するものになるはずだ。
プログラミング言語の改良に加え、VB.NETでは固有の標準ライブラリが.NET Base Class Library(BCL)のマルチ言語ライブラリに切り替えられた。BCLは、より多くの機能を包含し、Microsoftが保守性を向上させるために定義したスタイル・ガイドラインに準拠するなど、さまざまな面でビルトインされたVB APIより優れている。ただし、言語本体の場合と同様、BCLは従来のVB APIと直接的な互換性はなく、その点が.NETへスイッチしようと考える開発者たちのもう1つの潜在的な障害となっている。
●Visual Studio 2005での改良機能
MicrosoftはVisual Studio 2005(コード名:Whidbey、2005年上半期リリース予定。以下、VS 2005)で、C#などにも追加された、自動的にカスタマイズしてどのような型のデータにも対応する再利用可能なクラス(例えば顧客のリストやアドレスのリスト)を構築できる新しい言語機能「ジェネリクス」をサポートするなど、VB APIをさらに機能拡張する予定だ。またMicrosoftは、VS 2005でVBプログラマがBCLをさらに容易にアクセスできるように力を入れている。新しい“Myクラス”APIは、一般的に利用されるが見つけるのが難しいBCLの機能群を単一のネーム・スペースに収集することができる。ファイルの読み込みは、System.IO.StreamReaderだと3行のコードになるが、My.Computer.FileSystemでは1行で可能だ。
新しいAPIは、BCLをリプレイスするものではない。むしろBCLの上に構築され、VB開発者が頻繁に利用する機能を見つけやすく、あるいは使いやすくするものだ。
ユーザー・インターフェイスの変移
VBプログラミング言語を別にすれば、VBの開発環境を定義する最も重要な要素は、ユーザー・インターフェイス(UI)ツールとライブラリだ。プログラミング言語と同様、このUIも.NET移行で大幅に変更された。
●VB:VBフォーム・デザイナ
MicrosoftでRubyと呼ばれたVBフォーム・デザイナは、ユーザー・インターフェイス構築の基本メタファーを定義していた。コントロールをフォームにドラッグし、ダブルクリックすると、コード・エディタが開き、そこでプログラマは特定のイベントが発生したとき実行されるようにコードを記述することができた。このメタファーは.NET移行後も無傷で生き残ったが、実装は大きく異なり、Rubyとの互換性はない。
●VB.NET:Windowsフォームへ
VB.NETではWindowsフォームがRubyをリプレイスした。Rubyと同様、Windowsフォームもドラッグ・アンド・ドロップ環境を提供し、フォームの設計からコードの編集へ簡単に移れるようになっている。しかし、コントロールの名称やプロパティ、メソッド、イベントなどの詳細はかなり異なる。Windowsフォームはまた、Rubyと違ってVB.NET以外のプログラミング言語もサポートする(C#など)。
Windowsフォームのマルチ言語要求をサポートするため、若干の変更が行われた。しかし、UIの変更の多くは言語の変更と同様、長い間に蓄積されていったRubyの特異性を修正するためのものだった。Windowsフォームになじむと、ほとんどの開発者は洗練されたレイアウト・オプションや多言語サポートなど、Rubyよりはるかに改善されていると感じるはずだ。ただし、その分、移行には困難が伴う。
●VS 2005以降:Windowsフォームのサポートは不明
WindowsフォームはVS 2005にも実装されるが、それ以降については不透明だ。VS 2005の後のメジャーな改訂版「Orcas」では、次期WindowsクライアントOS「Longhorn」のサポートが約束されている。同OSには、さまざまな新機能とともに、新しいUIフレームワーク「Avalon」が採用される予定だ。Microsoftによると、AvalonとWindowsフォームには相互運用性があるというが、AvalonがWindowsフォームからの根本的な変更であることは、同社の技術資料からも明らかだ。Avalonが出荷された後、Windowsフォームに明るい未来があるとは思えない。
しかし、そのリスクは2つの要因によって軽減される。まず第1に、Longhornの出荷が2006年後半まで期待できず、企業や家庭への普及はさらにそれ以降になることだ。第2は、Longhornが出荷された後も、VBは間違いなくWindowsフォームのサポートを継続し、たとえMicrosoftがこのフレームワークの開発を中止しても、開発者はWindowsフォームアプリケーションのメンテナンスを維持できることだ。
INDEX | ||
Insider's Eye | ||
Visual Basic 2005はVBユーザーを救えるか? | ||
1.過去との決別/言語とベース・ライブラリの進化/ユーザー・インターフェイスの変移 | ||
2.データ・アクセスの混とんから脱却/VB.NETへの移行 − IT開発者の決断は? | ||
Insider's Eye |
- 第2回 簡潔なコーディングのために (2017/7/26)
ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている - 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう - 第1回 明瞭なコーディングのために (2017/7/19)
C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える - Presentation Translator (2017/7/18)
Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
|
|