コンピュータにより実現される方法であって、解決される型に関連づけられた第1のファイルを複数のファイルの中から探索するステップと、前記第1のファイルが存在するとの決定に応答して、前記型が名前空間を表す型であることを示す情報を送信するステップと、前記第1のファイルが存在しないとの決定に応答して、前記型に関連づけられた第1の名前空間レベル階層と一致するファイル名に関連づけられたファイルを前記複数のファイルの中から探索するステップと、前記型に関連づけられた第1の名前空間レベル階層と一致するファイル名が存在するとの決定に応答して、前記型に関連づけられた情報に関して前記ファイル名に関連づけられたファイルを処理するステップと、前記型に関連づけられた前記第1の名前空間レベル階層と一致する前記ファイル名が存在しないとの決定に応答して、前記型に関連づけられたさらに別の名前空間階層レベルが存在するかどうかを決定するステップと、さらに別の名前空間階層レベルが存在するとの決定に応答して、前記さらに別の名前空間階層レベルに関連づけられたファイル名を前記複数のファイルの中から探索するステップとを備える方法。前記第1のファイルを複数のファイルの中から前記探索するステップはさらに、前記型に関連づけられた名前と一致するファイル名を有するファイルを前記複数のファイルの中から探索する処理動作を備える、請求項1に記載のコンピュータにより実現される方法。前記第1のファイルを複数のファイルの中から前記探索するステップはさらに、前記型が存在する情報格納場所に関する知識なしに、前記第1のファイルを探索する処理動作を備える、請求項2に記載のコンピュータにより実現される方法。ユーザの介入なしに実行される、請求項1に記載のコンピュータにより実現される方法。前記複数のファイルは、メタデータファイルを備え、個々の前記メタデータファイルは、オペレーティングシステムのソフトウェアインターフェースに関連づけられた記述を含む、請求項1に記載のコンピュータにより実現される方法。前記メタデータファイルは、特定のプログラミング言語とは無関係に前記型を記述するように構成される、請求項5に記載のコンピュータにより実現される方法。コンピュータ読み取り可能な命令コードを備える1つ以上のコンピュータ読み取り可能なハードウェア記憶媒体であって、前記命令コードは、実行された際に、型解決モジュールの機能を実現し、前記型解決モジュールは、ユーザの介入なしに、型システムに関連づけられた型の名前空間と一致するファイル名を有するファイルについて1つ以上のメタデータファイルを探索し、前記ファイルが存在するとの決定に応答して、前記型に関連づけられた情報に関して前記ファイルを処理し、前記ファイルが存在しないとの決定に応答して、前記型に関連づけられたさらに別の名前空間階層レベルが存在するかどうかを決定する処理動作と、さらに別の名前空間階層レベルが存在するとの決定に応答して、前記さらに別の名前空間階層レベルと一致するファイル名を有するファイルについて前記1つ以上のメタデータファイルを探索する処理動作とを少なくとも一度実行するように構成され、前記少なくとも一度実行する動作は、前記別の名前空間階層レベルと一致するファイル名を有する前記ファイルが存在すると決定されたこと、または別の名前空間階層レベルが存在しないと決定されたこと、に応答して、少なくとも実行を一旦終了する、1つ以上のコンピュータ読み取り可能なハードウェア記憶媒体。前記別の名前空間階層レベルと一致するファイル名を有するファイルについて前記1つ以上のメタデータファイルを探索する処理動作は、前記名前空間階層レベルと一致する少なくとも部分的なファイル名の探索動作を備える、請求項7に記載の1つ以上のコンピュータ読み取り可能なハードウェア記憶媒体。前記型システムに関連づけられた型は、オペレーティングシステムに関連づけられたアプリケーションプログラミングインターフェースAPIを備える、請求項7に記載の1つ以上のコンピュータ読み取り可能なハードウェア記憶媒体。前記型システムに関連づけられた型の名前空間と一致するファイル名を有するファイルについて1つ以上のメタデータファイルを探索する処理動作はさらに、前記型が存在する情報格納場所の知識なしで実行される探索動作を備える、請求項7に記載の1つ以上のコンピュータ読み取り可能なハードウェア記憶媒体。発明の概要に関する以下の説明は、詳細な説明において以下にさらに説明される概念の選択を、単純化された形態で紹介するために提供される。発明の概要に関する以下の説明は、特許請求の範囲に記載された発明の主題において鍵となる技術的特徴、すなわち、技術的重要な特徴を限定することを意図したものではない。同時に、当該発明の概要に関する以下の説明は、特許請求の範囲に記載された発明の主題に係る技術的範囲を限定するために使用されることを意図したものでもない。本発明に係るさまざまな実施形態は、複数の異なる型システム同士の間における型解決の仕組みを抽象化するための機能を実現する。少なくとも1つの型が、プログラムに基づいてアクセス可能な1つ以上のファイルに記述され得る。いくつかの実施形態において、異なる型システムを使用するアプリケーションは、型の記述が存在する場所の知識なしに、その型システムの型に、プログラムに基づいてアクセスし、その型を解決することができる。あるいは、または加えて、プログラムに基づいてアクセス可能な1つ以上のファイルに含まれた型の記述は分析され、型システムの記述に少なくとも部分的に基づいて、プログラムに基づいてアクセス可能な1つ以上の新たなファイルへと再構築されることができる。同一の番号は、全図面を通して同様の特徴を参照するために使用される。概要本発明に係るさまざまな実施形態は、複数の異なる型システム同士の間における型解決の仕組みを抽象化するための機能を実現する。1つの型システムを使用するアプリケーションは、そのアプリケーションがどのように異なる型システム同士の間をブリッジするかについての知識を有する場合、もう1つの型システム中において呼び出しを実行し得る。たとえば、型システムの特性たとえば、データ型、データ型の振る舞い、関数呼び出しパラメータ、イベント、等が、プログラムに基づいてアクセス可能な1つ以上のファイルに記述され得る。アプリケーションは、そのようなファイルにアクセスすることによって、異なる型システムを使用した型解決を実行し得る。本発明に係るいくつかの実施形態においては、型解決の仕組みが抽象化され得るので、アプリケーションは、どのファイルにアクセスするか、および/または、どこにファイルが存在するか、といった予備知識なしに上述した型システムの特性記述にアクセスすることができる。以下の説明では、動作環境と題するセクションが提供され、1つ以上の実施形態が用いられ得る複数の環境を説明する。これに続き、型解決アーキテクチャと題するセクションにおいて、プログラムに基づいて上述した型解決を実行するシステムを実現可能にするアーキテクチャを説明する。次に、型記述の格納と題するセクションにおいて、型記述を格納するための柔軟性の高い仕組みを実現可能にするために使用され得るさまざまな方法を説明する。最後に、例示的なシステムと題するセクションにおいて、1つ以上の実施形態を実現するために利用され得る例示的なシステムを説明する。本発明に関し、以下に後述するさまざまな実施形態についての概要を提供したので、ここでは、本発明に係る1つ以上の実施形態が実現され得る基盤となる例示的な動作環境を考慮する。動作環境図1Aおよび図1Bは、1つ以上の実施形態に係る動作環境を示し、図1Aおよび図1Bにおいては、当該動作環境はそれぞれ、100aおよび100bとして一般化した形で示されている。図1Aは、以下において後述するとおり、1つ以上のメタデータファイルの生成に関連して利用され得る例示的な動作環境を示す。図1Aの環境は、ビルド段階の環境とみなされ得る。図1Bは、柔軟性の高い型システムを使用した型解決に関連して利用され得る例示的な動作環境を示す。図1Bの環境は、ランタイム時の環境とみなされ得る。本発明に係るいくつかの実施形態において、動作環境100aおよび100bは、少なくともいくつかの同様のコンポーネントを有する。したがって、簡潔化のために、図1Aおよび図1Bは一緒に説明される。図1Aに関連づけられたコンポーネントが、1XXaとの命名規則に従って命名されるコンポーネントとして特定される場合、図1Bに関連づけられる同様のコンポーネントは、1XXbとの命名規則に従って命名されるコンポーネントとして特定される。同様に、動作環境特有のコンポーネントは、単に1XXとして特定される。動作環境100aおよび100bはそれぞれ、1つ以上のプロセッサ104a、104bを有するコンピューティングデバイス102a、102b、および1つ以上のコンピュータ読み取り可能な記憶媒体106a、106bを含む。コンピュータ読み取り可能な記憶媒体は、コンピューティングデバイスに典型的に関連づけられる全ての形態の揮発性および不揮発性のメモリおよび/または記憶媒体を含み得る。そのような媒体の具体例を限定目的ではなく単に例示目的で挙げるならば、当該媒体は、ROM、RAM、フラッシュメモリ、ハードディスク、リムーバブルメディア、等を含み得る。コンピューティングデバイスの1つの特定の例が、図6において以下に示され説明される。加えて、コンピューティングデバイス102a、102bは、オペレーティングシステムOS108a、108b、およびアプリケーション110a、110bを含む。オペレーティングシステム108a、108bは、コンピューティングデバイス102a、102bのソフトウェアリソースおよび/またはハードウェアリソースを管理するように構成された機能を表す。これは、メモリ管理、ファイル管理、サービス、関数、リソース管理、周辺機器管理、等を含み得る。アプリケーション110a、110bは、コンピューティングデバイス102a、102b上で、典型的にはオペレーティングシステム108a、108bにより支援されて、実行するように構成されたソフトウェアを表す。アプリケーション110a、110bは、以下においてさらに説明されるように、オペレーティングシステム108a、108bの型システムと同一のおよび/または異なる型システムで実現され得る。コンピューティングデバイス102a、102bはまた、1つ以上のソフトウェアインターフェース112a、112bを含み、1つ以上のソフトウェアインターフェース112a、112bは、ソフトウェアおよび/またはアプリケーションによって提供される関数、サービス、データ、等への、プログラムに基づいたアクセス手段を表す。ソフトウェアインターフェース112a、112bは、オペレーティングシステム108a、108bおよび/またはアプリケーション110a、110bへの、プログラムに基づいたアクセスを可能にし得る。たとえば、アプリケーション110a、110bは、ソフトウェアインターフェース112a、112bを呼び出すことにより、オペレーティングシステム108a、108bによって提供される機能にアクセスし得る。いくつかの実施形態において、ソフトウェアインターフェースを介して提供される型システムとは異なる型システムを使用するアプリケーション112a、112bは、以下においてさらに説明するように、型の相違をプログラムに基づいて解決し得る。加えて、コンピューティングデバイス102a、102bはまた、1つ以上のメタデータファイル114a、114bを含み、1つ以上のメタデータファイル114a、114bは、ソフトウェアインターフェース112a、112b、オペレーティングシステム108a、108b、および/またはアプリケーション110a、110bに関連づけられた、入力パラメータの型、パラメータの呼び出し順序、インターフェース間の関係、等といった情報を含む、1つ以上の機械読み取り可能なファイルを表す。あるいは、または加えて、ソフトウェアインターフェースは、コンピューティングデバイス102a、102bに接続された周辺機器、たとえば、プリンタ、スキャナ、スマートフォン、等に関連づけられ得る。いくつかの実施形態において、メタデータファイル114a、114bは、以下においてさらに説明されるように、任意の適切な手法でインターフェースを記述するように構成され得る。コンピューティングデバイス102aはまた、マージモジュール116を含む。マージモジュール116は、1つ以上のメタデータファイルを読み出し、ファイルの内容を分析し、再構成された内容を含む1つ以上の新たなメタデータファイルを出力し得る機能を表す。本発明に係るいくつかの実施形態において、内容は、型記述に少なくとも部分的に基づいて再編成され得る。コンピューティングデバイス102bは、型解決モジュール118を含む。型解決モジュール118は、関連づけられた型データにアクセスするための要求を受信し、型解決情報の場所を特定するように構成された機能を表す。本発明に係るいくつかの実施形態において、型解決モジュール118は、情報が場所を変えても無関係に、ユーザ入力なしで型解決情報の場所を特定し得る。たとえば、型解決モジュール118は、以下においてさらに説明されるように、情報が第1のファイルから第2のファイルに移動した場合、ユーザ入力なしでインターフェース記述情報の場所を特定し得る。コンピューティングデバイス102a、102bの具体例を限定目的ではなく、例示目的で挙げるならば、これらは、例えば、デスクトップ型コンピュータ、ポータブル型コンピュータ、ノートブック型コンピュータ、携帯情報端末PDAのようなハンドヘルド型コンピュータ、携帯電話、等といった任意の適切なコンピューティングデバイスとして具現化され得る。例示的な動作環境を説明したので、ここでは、場所のファイル名および/または場所とは無関係に型解決を可能にするように構成された型解決アーキテクチャの説明を考慮する。型解決アーキテクチャプログラミング言語が技術的に進歩するにつれ、それらの能力も進歩する。たとえば、第1のプログラミング言語で書かれたアプリケーションが、第2のプログラミング言語で書かれたソフトウェアから呼び出され得る。本来、プログラミング言語は、異なる型システムを有する。したがって、異なる型システムの下に存在するソフトウェアを首尾よく呼び出すために、第1のプログラミング言語は、自身の型システムとは異なる型を解決するための技法を使用する。たとえば、プログラマは、型を変換するためのラッパーコードを手作業で書くことが可能である。あるいは、型システムの定義がファイルに格納され、プログラムに基づいてアクセスされ得る。型の定義を含むファイルにプログラムに基づいてアクセスすることは、機能および記述をアプリケーションがランタイムに決定することを可能にする。しかしながら、ファイルにアクセスするということは、どのファイルにアクセスべきであるかだけでなく、ファイルの格納場所も知っていなければならないことを暗に意味する。ファイルの内容が変わった場合および/またはファイルの格納場所が変わった場合、ファイルにアクセスしようと試みるアプリケーションは、適切に更新されない限り、場合によっては失敗し得る。これは時に、アプリケーションとファイルとの間の意図しない結合を生じさせる可能性がある。本発明に係るさまざまな実施形態は、複数の型システム同士の間における型解決の仕組みを抽象化するための機能を実現する。型解決に関連づけられた情報は、プログラムに基づいてアクセス可能なファイルに格納され得る。いくつかの実施形態において、1つの型システムを使用するアプリケーションは、ファイルへのアクセスを通じて、もう1つの型システムを使用することにより動的に型解決を実行し得る。あるいは、または加えて、アプリケーションは、どのファイルにアクセスするのか、および/または、どこにファイルが存在するのかに関する知識を持つことなしに、ファイルにアクセスし得る。図2を見ると、1つ以上の実施形態に係る例示的なアーキテクチャ200が示されている。アーキテクチャ200は、オペレーティングシステム202を含み、オペレーティングシステム202は、コンピューティングデバイス上で実行するように構成され得る。簡潔化のためにオペレーティングシステム202の全体が示されていないことが理解されるべきである。オペレーティングシステム202は、コンピューティングデバイスに関連づけられたリソースを管理するように構成された1つ以上のオペレーティングシステムコンポーネント204を含む。いくつかの実施形態において、オペレーティングシステムコンポーネント204は、リソースを管理することに関連づけられた1つ以上のサービスおよび/または特徴だけでなく、リソースへのプログラムに基づいたアクセスをも提供し得る。オペレーティングシステムコンポーネント204はまた、オペレーティングシステム202に関連づけられた基本的な要素だけでなく、基本的な要素から構築された複合的な要素をも含み得る。この例はオペレーティングシステム202によって提供される機能を外部からアクセス可能とするエクスポーズするアーキテクチャを示しているが、このアーキテクチャが、特許請求の主題の精神から逸脱することなく、他の適切なタイプのアプリケーションによって提供される機能を外部からアクセス可能とするために適用され得ることが認められ、理解されるべきである。本発明に係るいくつかの実施形態において、オペレーティングシステムコンポーネント204は、ここではオペレーティングシステムインターフェース206として示されている1つ以上のインターフェースを介して外部からアクセス可能とされ得るエクスポーズされ得る。このようなインターフェースは、任意の適切な形態のインターフェース、たとえば、アプリケーションプログラミングインターフェースAPIとすることが可能である。アプリケーションは、以下においてさらに説明されるように、呼び出し中および/または実行中のオペレーティングシステムインターフェース206により、オペレーティングシステムコンポーネント204によって提供される機能にアクセスし得る。本実施形態に係るいくつかのケースにおいて、アプリケーションは、オペレーティングシステムインターフェース206を記述するために使用される型システムとは異なる型システムを利用する。いくつかのケースにおいて、オペレーティングシステムインターフェース206は、アプリケーションバイナリインターフェースABIを含み得る。ABIは、機械により解釈実行可能な命令語レベルで、関数、方法、API、等を呼び出すためのバイナリコントラクトを記述する。バイナリコントラクトは、関数に関連づけられた識別子または名前、関数を呼び出すために使用され得るシグネチャ、関数に受け渡されるパラメータの順序、および/または、パラメータに関連づけられたデータ型、等を含み得る。あるいは、または加えて、バイナリコントラクトは、型システムの少なくとも1つの型に関連づけられたエクスポーズ動作の挙動に関する定義および/または規則を含み得る。オペレーティングシステム202はまた、さまざまなメタデータ208を含む。メタデータ208は、関連づけられたオペレーティングシステムインターフェース206のさまざまな態様を記述する型解決情報、たとえば、バージョン情報、どの方法が利用可能か、インターフェースがどのパラメータを採用するか、パラメータのデータ型、パラメータを受け渡す順序、データ型の振る舞い、および/または解決情報、等を含み得る。本発明に係るいくつかの実施形態において、メタデータは、インターフェースに関連づけられた階層情報、たとえば、インターフェース間の関係を記述した、および/または、オブジェクト指向でインターフェースを記述した情報、を含み得る。メタデータはまた、クラスの記述、クラスの関連づけられた方法およびパラメータ、等を含み得る。本実施形態に係るいくつかのケースにおいて、メタデータは、抽象型システムたとえば、特定のプログラミング言語と無関係の型システムを使用してインターフェースを記述し得る。あるいは、または加えて、メタデータは、特定の型システム、たとえば、抽象型システムの記述を含み得る。すると、特定のプログラミング言語は、特定の型システムたとえば、抽象型システムの記述を特定のプログラミング言語にマッピングし得る。さらに、どのインターフェースが利用可能かを決定することを望むプログラマは、手作業で、および/またはプログラムに基づいて、各インターフェースの記述にアクセスすることができる。たとえば、どのインターフェースがオペレーティングシステムコンポーネント204のアクセス手段として存在するか、インターフェースがどの型システムで記述されているか、どのようにそれらを呼び出すか、を決定するために、プログラマは、関連づけられたメタデータ208にアクセスし得る。アーキテクチャ200はまた、1つ以上のアプリケーション210を含む。アプリケーション210は、1つ以上のプログラミング言語、たとえば、HTML、JavaScript登録商標、VisualBasic、C、C、等から生成された1つ以上のアプリケーションを含み得る。いくつかの実施形態において、アプリケーション210は、オペレーティングシステムコンポーネントへの1つ以上の呼び出しを含む。いくつかのケースにおいて、アプリケーション210は、まず、どのインターフェースが利用可能かをプログラムに基づいて決定し、次に、決定されたインターフェースのうちの1つ以上への呼び出しを行うように構成され得る。いくつかのケースにおいて、アプリケーション210は、以下においてさらに説明するように、1つ以上の生成された言語投影モジュール212からの支援を受けて、インターフェースにアクセスする。1つ以上の実施形態において、生成された言語投影モジュール212は、抽象型の定義を特定のプログラミング言語にマッピングする。任意の適切なプログラミング言語がマッピングされることができ、それらの例は上述したとおりである。いくつかの実施形態において、生成された言語投影モジュールは、各プログラミング言語毎に一意であり得る。本発明に係る他の実施形態において、生成された言語投影モジュールは、多目的な機能モジュールであり、複数のプログラミング言語によって利用され得る。上述したマッピングは、抽象型システムを使用して記述される現在および未来のインターフェースが、追加のプログラミングステートメントたとえば、ラッパー関数なしに特定のプログラミング言語にアクセスできるようにすることができる。上述したマッピングはさらに、特定のプログラミング言語にとってネイティブの手法で、当該特定のプログラミング言語がインターフェースを呼び出すことを可能にする。任意の適切なタイプの情報、たとえば、クラス、データ型、関数ポインタ、構造、等が、マッピングされ得る。インターフェースの記述は、アプリケーションがどのようにインターフェースを呼び出すべきかを記述するだけでなく、インターフェースに関連づけられた型システムの挙動を記述するためにも使用され得る。記述の情報格納場所が特定されたことに応答して、アプリケーションは、どのようにインターフェースを呼び出すかを動的に決定し、アプリケーションとインターフェースとの間における型システムの相違を解決し得る。本発明に係るいくつかの実施形態において、異なる型システムを使用するアプリケーションは、型記述が存在する情報格納場所の知識なしに、プログラムに基づいて、インターフェースによって利用される型にアクセスし、その型の型解決を実行し得る。あるいは、または加えて、以下においてさらに説明するように、どのような方法で記述がグループ化されるかを特定することにより、自動的な型解決を実現可能にすることができる。以下の実施例においては、JavaScriptを使用してアプリケーションを書くプログラマがいると仮定する。この例はJavaScriptを使用した実現形態を説明するが、任意のプログラミング言語が特許請求の範囲に記載された技術思想から逸脱することなく使用され得ることが当業者にとって自明なものとして認められ理解されるべきである。外部の機能にアクセスするために、プログラマは、機能に関連づけられた名前空間および/または型を識別するように構成されたステートメントをソースコード中に含めることができる。たとえば、外部の型は、ソースコード内に以下のようにして含められ、および/または、以下のソースコードで記述され得る。OperatingSystem.Foo.Bar.Type1この特定の例において、Type1は、アクセスされる機能を表現する。これは、任意の適切なタイプの機能であることができ、その例は、上述および後述されるとおりである。上記シンタックスは、Type1の情報格納場所を特定するために横断的に走査することができる多層構造の名前空間階層を表現する。最も高い階層レベルにおいては、Type1は、OperatingSystemとして識別された名前空間に存在する。OperatingSystem内にFooとして識別された名前空間が存在する。同様に、Foo内にはBarとして識別された名前空間が存在し、BarにはType1が存在する。したがって、シンタックスは、Type1の論理的な情報格納場所を識別するために使用され得る。しかしながら、Type1の物理的な情報格納場所たとえば、どのファイルにType1情報が存在するか、および/または、どのディレクトリにファイルが存在するかは時間の経過に従って変わる可能性がある。従来、物理的な情報格納場所は、アプリケーション内においてパスおよびファイル名を直接的または間接的にハードコーディングすることによって決定されることができた。したがって、Type1情報のファイル名および/またはパスが変わった場合、アプリケーションによって利用されるファイル名および/またはパスの任意の直接的または間接的な参照は、更新されるまで不適切であろう。さらに、直接的または間接的な参照が更新されるまで、アプリケーションは、場合によっては適切に機能することができなかった。本発明に係るさまざまな実施形態は、型解決の仕組みを抽象化するための機能を実現する。たとえば、型は、関連づけられた型解決情報の情報格納場所に関する完全な知識なしに、アプリケーションにより、プログラムに基づいて解決されることができる。本発明に係るいくつかの実施形態において、型解決情報は、情報格納場所を表している新たな情報によって、解決情報を利用するアプリケーションを更新せずに、再配置され得る。アプリケーションは、どのファイル中に型解決情報が存在するかに関わらず、型解決情報の場所を特定するように構成されることが可能となる。図3を見ると、本発明の1つ以上の実施形態に係る方法を実施するための一連の処理ステップを説明したフローチャートが示されている。当該方法は、任意の適切なハードウェア、ソフトウェア、ファームウェア、またはそれらの組み合わせによって実行され得る。本発明に係る少なくともいくつかの実施形態において、当該方法の実施態様は、1つ以上のコンピューティングデバイス上で実行中の1つ以上の適切に構成されたソフトウェアモジュールたとえば、図1Bの型解決モジュール118によって実現され得る。本発明に係るいくつかの実施形態において、当該方法は、ユーザによる介入なしに実行され得る。ステップ302は、解決される型と一致するファイル名を有するファイルを探索する。これは、上述した複数のメタデータファイルの探索を含み得る。上記シンタックスの例を参照すると、アプリケーションがOperatingSystem.Foo.Bar.Type1にアクセスすることに応答して、ステップ302は、OperatingSystem.Foo.Bar.Type1という名前を有するファイルを探索する。任意の適切なタイプの探索が実行され得る。たとえば、探索は、型とファイル名との間の完全一致、型とファイル名との間の部分一致、等を探すように構成され得る。あるいは、または加えて、探索は、1つのディレクトリ、複数のディレクトリ、および/またはサブディレクトリ、またはそれらの任意の組み合わせの中を探索するように構成され得る。ステップ304は、ファイルが存在するかどうかを決定する。ファイルが存在するとの決定に応答して、ステップ306は、型が名前空間であることを示す情報を送信する。ファイルが存在しないとの決定に応答して、ステップ308は、解決される型に関連づけられた名前空間と一致するファイル名を探索する。いくつかのケースにおいて、これは、どの名前空間上を探索するかを決定するために、名前空間の階層を表す情報を含むストリングを操作することを含み得る。上述した例において、Type1は、名前空間の階層において3階層下に配置されるものとして示されている。ストリングに対する操作は、型たとえば、Type1を表す部分を削除し、名前空間の階層を表す部分を残すように実行され得る。ここで、ステップ308は、名前空間の階層OperatingSystem.Foo.Barに関連づけられた名前を探索するだろう。上記と同様に、この探索は、完全一致または部分一致の探索方法に従って探索を実行し、1つのディレクトリの中を探索し、さらにそのサブディレクトリの中を探索する、といった具合に構成され得る。ステップ310は、ファイル名に関連づけられたファイルが存在するかどうかを決定する。ファイルが存在するとの決定に応答して、ステップ312は、型に関連づけられた情報のためにファイルを処理する。ステップ314は、型に関連づけられた情報がファイル内に配置されているかどうかを決定する。型に関連づけられた情報がファイル内にあるとの決定に応答して、ステップ316は、情報を戻す。たとえば、情報は、呼び出しているプログラムに戻され得る。しかしながら、型に関連づけられた情報がファイル内にないとの決定に応答して、処理はステップ318に進む。ステップ318においては、より高い階層レベルの名前空間と一致するファイル名が探索される。ステップ318におけるこの探索動作は、たとえば、ステップ310の実行時におけるファイルが存在しないとの決定に応答する形で、または、ステップ314の実行時に、型に関連づけられた情報の格納場所をファイル内において特定することができないことに応答する形で実行することが可能である。より高い階層レベルの名前空間は、任意の適切な手法で決定され得る。たとえば、上記の例では、ストリングが、名前空間階層における1つ上のレベルたとえば、OperatingSystem.Fooを反映させるようにさらに操作され得る。ステップ318は、より高い階層レベルの名前空間を決定し、関連づけられた名前を有するファイルを探索する。ステップ320は、ファイル名に関連づけられたファイルが存在するかどうかを決定する。ステップ310のケースのように、ファイルが存在すると決定された場合、処理は、ステップ312、314、および/または316に進み、ファイルが、関連づけられた型情報のために処理される。ファイルが存在しないとの決定に応答して、ステップ322は、さらに別の名前空間階層レベルが存在するかどうかを決定する。これは、任意の適切な手法で決定され得る。たとえば、レベル分離文字についてストリングを探索することができる。上記の例では、シンタックス.が、名前空間階層のレベルを区別する。さらに別の名前空間階層レベルが存在するとの決定に応答して、上述した処理が繰り返され、処理はステップ318に戻り、新たに決定された名前空間を有するファイルを探索する。ステップ318、320、および322は、適切なファイルが見つかるまで、または、名前空間階層の最上部に到達し、最上部が探索されるまで、繰り返し実行される。さらに別の名前空間階層レベルが存在しないとの決定に応答して、ステップ324はエラーを戻す。これは、例外処理を実行すること、ポップアップダイアログボックスを表示すること、等を含み得る。上述した方法の使用により、複数のファイルおよび/または情報格納場所が、型解決情報について探索され得る。説明したように、型の探索は、階層名前空間情報に少なくとも部分的に基づき得る。図3は、より低い名前空間階層レベルたとえば、OperatingSystem.Foo.Bar.Type1から始まり、型の格納場所が特定されるか又は最上部の名前空間階層レベルたとえば、OperatingSystemに到達するまで、名前空間の各階層レベルを上に向かって横断的に走査するように実行される型の探索動作を説明する。しかしながら、この探索動作は、任意の適切な順序で実行され得る。本発明に係るいくつかの実施形態では、型の探索動作は、より高い名前空間階層レベルたとえば、OperatingSystemから始まり、型の格納場所が特定されるか最下部の名前空間階層レベルたとえば、OperatingSystem.Foo.Bar.Type1に到達するまで、名前空間の各階層レベルを下に向かって横断的に走査し得る。名前空間階層上の探索は、型解決情報がどこに存在し得るかを抽象化することができ、さらに、型解決情報にアクセスするアプリケーションに影響を及ぼさずに型解決情報の情報格納場所を変更することを可能にする。場所のファイル名および/または場所とは無関係に型解決を可能にするように構成された型解決アーキテクチャが考慮されたので、ここでは、1つ以上の実施形態に係るフレキシブルな型記述の格納の説明を考慮する。型記述の格納メタデータファイルが、ソフトウェアインターフェースのさまざまな態様を記述するために使用され得る。上述したように、メタデータファイルは、クラス階層、抽象型システム、関連づけられた方法、プロパティ、およびイベント、等によってインターフェースを記述する情報を含み得る。本実施形態に係るいくつかのケースにおいて、関連づけられた情報は、複数のファイル内に存在し得る。たとえば、異なるメタデータファイルが、同一の名前空間に関連する情報を含み得る。複数のメタデータファイルは、メタデータファイルの開発者に高い柔軟性を与え得る一方で、それは時に、メタデータファイルをユーザが探索する際の妨げとなり得る。以下の例では、各名前空間が、それ独自の関連づけられたメタデータファイルを有する例を考慮する。分割の観点からは、各名前空間のための別個のファイルは、名前空間に対する変更を、関連づけられたファイルに分離することができる。しかしながら、探索の観点からは、情報について複数のファイルを探索しなくてはならないことは、ランタイムでの探索時の性能を低下させ得る。さらに、知識の観点からは、何の情報が何のファイルの中にあるかの追跡を維持することは、ファイル数が増加すると複雑化し得る。本発明に係るさまざまな実施形態は、型解決情報が存在するファイル名およびファイル格納場所の予備知識なしの型解決を実現可能にする。複数の入力ファイルから成るファイル群の内容が分析され、少なくとも部分的には合成規則に基づいて分割され得る。複数の出力ファイルから成るファイル群を生成することができ、分割された内容を含むように構成される。出力ファイルは、内容がどこに存在するかの予備知識なしに内容の格納場所を特定することを可能にし得る。例として、図4を見ると、1つ以上の実施形態に係る、記述言語ファイル、メタデータファイル、およびマージモジュール間の関係が示されている。本発明に係る少なくともいくつかの実施形態において、この関係図に示されたモジュールは、ソフトウェア、ハードウェア、またはそれらの任意の組み合わせ、たとえば、図1Aのマージモジュール116として実現され得る。例示され説明された実施形態において、Foo.idl402は、1つ以上のインターフェースを記述するように構成された記述言語ファイルを表す。本発明に係るいくつかの実施形態において、インターフェースは、図1のオペレーティングシステムインターフェース108および/またはアプリケーション110といった、オペレーティングシステムおよび/またはアプリケーションに関連づけられ得る。記述言語ファイルは、任意の適切な記述、マーク付け言語、および/またはシンタックスを使用して、たとえば、インターフェース定義言語IDL、拡張可能なマーク付け言語XML、等を用いて、インターフェースを記述し得る。この特定の例において、Foo.idlは、IDLファイルを表す。Foo.idl402は、3つの型の記述、TypeFoo.Bar.Type1404、TypeFoo.Bar.Type2406、およびTypeFoo.Bar.Type3408を含む。3つのエントリを用いて説明するが、任意の適切な数の記述、ならびに型の記述が、特許請求の範囲に記載された発明の技術思想から逸脱することなく、Foo.idl402に含まれ得ることが認められ理解されるべきである。たとえば、型は、クラス、インターフェース、方法、プロパティ、イベント、等の記述を含み得る。この例では、型404、406、および408は、Foo.Barの階層名前空間に含まれるものとして記述される。図4はまた、第2の記述言語ファイル、Bar.idl410を示す。Foo.idl402と同様に、Bar.idl410は、3つの型、TypeFoo.Bar.Type4412、TypeFoo.Quux.Type1414、およびTypeFoo.Quux.Type2416を含む記述言語ファイルを表す。型412、414、および416のシンタックスを参照すると、Bar.idl410は、名前空間Foo.Barにおける少なくとも1つの型、および、名前空間Foo.Quuxにおける少なくとも2つの型を含む。Foo.metadata418は、Foo.idl402に少なくとも部分的に基づいた機械読み取り可能なメタデータファイルを表す。説明は省略するが、本発明に係るいくつかの実施形態において、Foo.metadata418は、Foo.idl402からコンパイラによって生成され得る。Foo.idl402と同様に、Foo.metadata418は、メタデータファイルにネイティブなフォーマットの型の記述、Foo.Bar.Type1420、Foo.Bar.Type2422、およびFoo.Bar.Type3424を含む。Bar.metadata426もまた、Bar.idl410に少なくとも部分的に基づいた機械読み取り可能なメタデータファイルを表す。Foo.metadata418のケースのように、Bar.metadata426は、型の記述、Foo.Bar.Type4428、Foo.Quux.Type1430、およびFoo.Quux.Type3432を含む。図4に含まれるのは、マージモジュール434である。マージモジュール434は、1つ以上の入力ファイルを受け取ると、判定基準および/または規則のセットに基づいて1つ以上の出力ファイルを生成し得る。たとえば、入力ファイルを探索する入力ディレクトリ、出力ファイルを置く出力ディレクトリ、適用する検査のレベル、どの名前空間階層レベルで統合および/または分割するか、どのようにして出力ファイルに命名するか、出力ファイルをいくつ生成するか、どの深度でメタデータファイルが生成されるべきか、等を指定する入力コマンドおよび/または規則が、マージモジュール434に適用され得る。判定基準および/または規則は、任意の適切な手法、たとえば、1つ以上の規則を含むコマンドラインおよび/またはmakefileによって、マージモジュール434に与えられ得る。この例では、Foo.metadata418およびBar.metadata426が、マージモジュール434への入力である。マージモジュール434は、入力ファイルをオペランド解析し、指示どおりに出力ファイルを生成する。ここで、マージモジュール434は、2つの出力ファイル、Foo.Bar.metadata436およびFoo.Quux.metadata438を生成する。Foo.Bar.metadata436は、Foo.Barの名前空間に関連する型たとえば、Foo.Bar.Type1440、Foo.Bar.Type2442、Foo.Bar.Type3444、およびFoo.Bar.Type4446を含む。同様に、Foo.Quux.metadata438は、Foo.Quuxの名前空間に関連する型たとえば、Foo.Quux.Type1448、Foo.Quux.Type2450を含む。上記の例におけるように、Foo.Bar.metadata436およびFoo.Quux.metadata438は、場合によっては関連づけられた入力ファイルから再編成および/または再グループ化されたデータを含む、機械読み取り可能なメタデータファイルを表す。したがって、マージモジュール434は、複数のファイルからの内容を分析し、判定基準のセットに従って内容を再構築し得る。本発明に係るいくつかの実施形態において、ファイルの命名規則が、抽象型解決を可能にするために利用され得る。たとえば、名前空間階層が命名規則として使用され得る。図4において、ファイルFoo.Bar.metadata436およびFoo.Quux.metadata438は、それらのファイル名に、関連づけられた名前空間階層たとえば、それぞれ、Foo.BarおよびFoo.Quuxを含む。この命令規則を利用することにより、型情報は、特定のファイル名ではなく、それに関連づけられた名前空間に基づいて、探索されることが可能である。あるいは、または加えて、出力ファイルは、複数の名前空間階層レベルのデータを含み得る。図4において、Foo.Bar.metadata436は、Foo.Barの名前空間にデータを含むものとして示されている。しかしながら、Foo.Bar.metadata436はまた、Foo.Bar.Level1.Level2.Level3という名前空間階層レベルに存在する型情報を含むように構成され得る。したがって、命名規則は、ファイル内に含まれ得る最も高いレベルの名前空間を示す。加えて、適切な型を格納している格納場所が特定されるまで、図3において説明されたような探索アルゴリズムが、異なる階層レベルの名前空間および関連づけられたファイルを横断的に走査するために用いられ得る。同一の名前空間階層レベルにおける全ての型情報を同一のファイル内に存在するように構成することにより、特定のレベルに関連づけられた情報は、情報を利用するアプリケーションに影響を及ぼさずにファイルからファイルへ移動させられることが可能となる。名前空間階層に関連づけられた情報は、任意の適切な手法で分割され得る。たとえば、複数の階層レベルが同一のファイル内に存在するたとえば、Foo.Bar、Foo.Bar.Level1、およびFoo.Bar.Level2がすべて、Foo.Bar.metadataと命名されたファイル内に存在するようにすることも可能であるし、または、各ファイルがそれ独自の関連づけられたファイルを有するたとえば、Foo.Barのレベルにおける情報が、Foo.Bar.meatadata内に存在し、Foo.Bar.Level1における情報が、Foo.Bar.Level1.metadataファイル内に存在するようにすることも可能である、といった具合である。情報がそれに関連づけられた名前空間階層に従って置かれる場合、型解決は、特定のファイル名への依存を除くことによって、抽象化され得る。ここで図5を見ると、本発明の1つ以上の実施形態に係る方法を実施するための一連の処理ステップを説明したフローチャートが示されている。この方法は、任意の適切なハードウェア、ソフトウェア、ファームウェア、またはそれらの組み合わせによって実行され得る。本発明に係る少なくともいくつかの実施形態において、この方法の実施態様は、図1Aのマージモジュール116のような、1つ以上のコンピューティングデバイス上で実行中の、適切に構成された1つ以上のソフトウェアモジュールによって実現され得る。ステップ502は、1つ以上の出力ファイルを生成することに関連づけられた1つ以上の入力判定基準を受信する。本発明に係るいくつかの実施形態において、当該入力判定基準は、情報をどのようにして1つ以上の出力ファイルへと分割するかを指定する規則を含み得る。たとえば、当該入力判定基準は、出力ファイルに一緒にグループ化する1つ以上の名前空間階層レベルを指定し得る。あるいは、または加えて、当該入力判定基準は、たとえば、どのファイルおよび/またはどのディレクトリから情報を引き出すかを指定することによって、どこで情報を見つけるかを記述し得る。1つ以上の入力判定基準を受信することに応答して、ステップ504は、1つ以上のソフトウェアインターフェースと関連づけられた情報を含む1つ以上の入力ファイルを受信する。当該情報は、抽象型システムを使用するソフトウェアインターフェースの記述、オブジェクト指向の関連づけ、方法、プロパティ、関数ポインタ、入力および/または出力パラメータ、型システム情報、等といった、任意の適切なタイプの情報とすることが可能である。本発明に係る実施形態において、型情報は、名前空間の階層情報を含み得る。1つ以上の入力ファイルを受信することに応答して、ステップ506は、1つ以上の入力判定基準に少なくとも部分的に基づいて情報を分析する。これは、どの名前空間階層の型情報が各ファイル内に存在するかを決定するために入力ファイルを分析することを含み得る。情報を分析することに応答して、ステップ508は、当該情報を含む少なくとも1つの出力ファイルを生成する。本発明に係るいくつかの実施形態において、当該出力ファイルは、上述した入力判定基準に少なくとも部分的に基づいて異なるファイルに再分割された情報を含み得る。当該出力ファイルは、任意の適切な手法で構成されることができ、そのような手法の例は、上述されたとおりである。たとえば、当該出力ファイルは、メタデータファイルに含まれる名前空間階層に基づいた命名規則を用いて命名されたメタデータファイルとして構成され得る。あるいは、または加えて、当該出力ファイルは、複数のレベルの名前空間階層を含むように構成され得る。名前空間階層情報を出力ファイル中に一緒にグループ化することによって、アプリケーションは、特定のファイル名ではなく、名前空間階層レベルに基づいて情報を探索することができる。これは、アプリケーションに影響を及ぼさない形で情報の分割を柔軟に実行することを可能にする。アプリケーションがどの名前空間階層レベルに特定の型が存在するのかを知っている限り、どのように名前空間階層レベルがグループ化されるかに関わらず、関連づけられた型情報の情報格納場所が出力ファイル中で特定され得る。柔軟性の高い型記述情報の格納方法を説明したので、以下の説明においては、本発明の1つ以上の実施形態に係る例示的なシステムの説明を考慮する。例示的なシステム図6は、上述したさまざまな実施形態を実現するために使用され得る例示的なコンピューティングデバイス600を示す。コンピューティングデバイス600は、たとえば、図1Aおよび図1Bのコンピューティングデバイス102aおよび/または102b、または任意の他の適切なコンピューティングデバイスとすることが可能である。コンピューティングデバイス600は、1つ以上のプロセッサまたは処理ユニット602、1つ以上のメモリおよび/またはストレージコンポーネント604、1つ以上の入力/出力I/Oデバイス606、および、さまざまなコンポーネントおよびデバイスに互いに通信することを可能にさせるバス608を含む。バス608は、メモリバスまたはメモリコントローラ、周辺機器用バス、アクセラレイティッドグラフィックスポート、および、さまざまなバスアーキテクチャのうちのいずれかを使用するプロセッサまたはローカルバスを含む、いくつかのタイプのバス構造のうちのいずれかの1つ以上を表す。バス608は、有線および/または無線バスを含み得る。メモリ/ストレージコンポーネント604は、1つ以上のコンピュータハードウェア記憶媒体を表す。コンポーネント604は、揮発性媒体たとえば、ランダムアクセスメモリRAMおよび/または不揮発性媒体たとえば、読み出し専用メモリROM、フラッシュメモリ、光学ディスク、磁気ディスク、等を含み得る。コンポーネント604は、固定媒体たとえば、RAM、ROM、固定ハードドライブ、等だけでなく、取り外し可能な媒体たとえば、フラッシュメモリドライブ、リムーバブルハードドライブ、光学ディスク、等を含み得る。1つ以上の入力/出力デバイス606は、ユーザによるコンピューティングデバイス600へのコマンドおよび情報の入力を可能にし、また、ユーザおよび/または他のコンポーネントまたはデバイスへの情報の提示を可能にする。入力デバイスの例は、キーボード、カーソル操作用デバイスたとえば、マウス、マイクロフォン、スキャナ、等を含む。出力デバイスの例は、ディスプレイ装置たとえば、モニタまたはプロジェクタ、スピーカー、プリンタ、ネットワークカード、等を含む。さまざまな技法が、ソフトウェアまたはプログラムモジュールの一般的なコンテキストで、本明細書において説明され得る。一般的に、ソフトウェアは、特定のタスクを実行するか、または特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造、等を含む。これらのモジュールおよび技法の実現は、何らかの形態のコンピュータ読み取り可能な媒体上に記憶されるか、またはそのような媒体によって伝送され得る。コンピュータ読み取り可能な媒体は、コンピューティングデバイスによってアクセス可能な、任意の利用可能な単数の媒体または複数の媒体とすることが可能である。限定ではなく例として、コンピュータ読み取り可能な媒体は、コンピュータ読み取り可能な記憶媒体を備え得る。コンピュータ読み取り可能な記憶媒体は、コンピュータ読み取り可能な命令、データ構造、プログラムモジュール、または他のデータ、といった情報の記憶のための、任意の方法または技術において実現される、揮発性および不揮発性の、取り外し可能および取り外し不可能な、ハードウェア媒体を含む。コンピュータ読み取り可能なハードウェア記憶媒体は、RAM、ROM、EEPROM、フラッシュメモリ、または他のメモリ技術、CD-ROM、デジタル多用途ディスクDVD、または他の光学ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、または他の磁気ストレージデバイス、または、所望の情報を記憶するために使用可能かつコンピュータによってアクセス可能な任意の他の媒体を含むが、これらに限定されない。結論さまざまな実施形態は、複数の型システム間の型解決を抽象化するための能力を提供する。少なくとも1つの型が、プログラムに基づいてアクセス可能な1つ以上のファイルに記述され得る。いくつかの実施形態において、異なる型システムを使用するアプリケーションは、型の記述が存在する場所の知識なしに、少なくとも1つの型システムの型に、プログラムに基づいてアクセスし、その型を解決することができる。あるいは、または加えて、プログラムに基づいてアクセス可能な1つ以上のファイルに含まれる型の記述は分析され、型の記述に少なくとも部分的に基づいて、プログラムに基づいてアクセス可能な1つ以上の新たなファイルへと再構築されることができる。主題は、構造上の特徴および/または方法の動作特有の表現で説明されたが、添付の請求項において定義される主題は、必ずしも上述した特定の特徴または動作に限定されるものではないことが理解されるべきである。そうではなく、上述した特定の特徴および動作は、請求項を実現する例示的な形態として開示されている。