JP5852246B2 - 柔軟性の高いメタデータの合成 - Google Patents

Description

コンピューティング・デバイスは多くの場合、コンピューティング・デバイスのハードウェアおよび／またはソフトウェア・リソースを管理するための手法として、オペレーティングシステムを実行する。いくつかのケースにおいて、オペレーティング・システムは、単純化され、プログラムに基づいた、リソースへのアクセスを提供し得る。たとえば、オペレーティングシステムは、さまざまなコンポーネントを外部からアクセス可能とするためのアプリケーション・プログラミング・インターフェース（ＡＰＩ）を含み得る。アプリケーションを実装するのに使用されたプログラミング言語および／または型システムが、ＡＰＩにより提供されるプログラミング言語および／または型システムとは異なっていたとしても、アプリケーションによるＡＰＩを首尾よく呼び出すことが出来る場合がある。がしかし、これは、どの型がＡＰＩに関連づけられているかをアプリケーションが知っている場合に限られる。たとえば、ＡＰＩは、１つ以上の入力および／または出力パラメータを含み得る。ＡＰＩを呼び出すために、プログラマは、ＡＰＩのパラメータだけでなく、どのデータ型が各パラメータに関連づけられているかも決定しなくてはならない。

上述したように、呼び出し側で使用されるプログラミング言語の型システムとは異なる型システムによってＡＰＩが記述されている場合がある。そこで、異なる型システムを橋渡し（ブリッジング）するために、互いに異なる型システム同士の間を翻訳するためのラッパー・コードをプログラマが書くことが一般的に行われている。プログラマがプログラムの中にＡＰＩアクセスを含ませるための１つの手法は、１つ以上のファイルおよび／または名前空間によるＡＰＩ定義をソースコード中に含ませることである。ソースコード中にファイルおよび／または名前空間を首尾よく組み込むために、ソースコードは、ファイル／名前空間の特定の場所の参照（たとえば、ハード・コーディングされたパス、そのパスによりレジストリ・キーにアクセスする、等）を含むように構成され得る。場所、ファイル名、および／または、名前空間の名前が変わった場合、コードおよび／またはソフトウェア・ツールが適切な変更によって更新されるまで、連係は中断する。

発明の概要に関する以下の説明は、詳細な説明において以下にさらに説明される概念の選択を、単純化された形態で紹介するために提供される。発明の概要に関する以下の説明は、特許請求の範囲に記載された発明の主題において鍵となる技術的特徴、すなわち、技術的重要な特徴を限定することを意図したものではない。同時に、当該発明の概要に関する以下の説明は、特許請求の範囲に記載された発明の主題に係る技術的範囲を限定するために使用されることを意図したものでもない。

本発明に係るさまざまな実施形態は、複数の異なる型システム同士の間における型解決の仕組みを抽象化するための機能を実現する。少なくとも１つの型が、プログラムに基づいてアクセス可能な１つ以上のファイルに記述され得る。いくつかの実施形態において、異なる型システムを使用するアプリケーションは、型の記述が存在する場所の知識なしに、その型システムの型に、プログラムに基づいてアクセスし、その型を解決することができる。あるいは、または加えて、プログラムに基づいてアクセス可能な１つ以上のファイルに含まれた型の記述は分析され、型システムの記述に少なくとも部分的に基づいて、プログラムに基づいてアクセス可能な１つ以上の新たなファイルへと再構築されることができる。

同一の番号は、全図面を通して同様の特徴を参照するために使用される。

図１Ａは、１つ以上の実施形態に係る、本明細書で説明されるさまざまな原理が用いられ得る動作環境を示す図である。

図１Ｂは、１つ以上の実施形態に係る、本明細書で説明されるさまざまな原理が用いられ得る動作環境を示す図である。

図２は、１つ以上の実施形態に係るアーキテクチャを示す図である。

図３は、１つ以上の実施形態に係るフローチャートである。

図４は、１つ以上の実施形態に係る関係図である。

図５は、１つ以上の実施形態に係るフローチャートである。

図６は、１つ以上の実施形態を実現するために利用され得る例示的なシステムを示す図である。

概要
本発明に係るさまざまな実施形態は、複数の異なる型システム同士の間における型解決の仕組みを抽象化するための機能を実現する。１つの型システムを使用するアプリケーションは、そのアプリケーションがどのように異なる型システム同士の間をブリッジするかについての知識を有する場合、もう１つの型システム中において呼び出しを実行し得る。たとえば、型システムの特性（たとえば、データ型、データ型の振る舞い、関数呼び出しパラメータ、イベント、等）が、プログラムに基づいてアクセス可能な１つ以上のファイルに記述され得る。アプリケーションは、そのようなファイルにアクセスすることによって、異なる型システムを使用した型解決を実行し得る。本発明に係るいくつかの実施形態においては、型解決の仕組みが抽象化され得るので、アプリケーションは、どのファイルにアクセスするか、および／または、どこにファイルが存在するか、といった予備知識なしに上述した型システムの特性記述にアクセスすることができる。

以下の説明では、「動作環境」と題するセクションが提供され、１つ以上の実施形態が用いられ得る複数の環境を説明する。これに続き、「型解決アーキテクチャ」と題するセクションにおいて、プログラムに基づいて上述した型解決を実行するシステムを実現可能にするアーキテクチャを説明する。次に、「型記述の格納」と題するセクションにおいて、型記述を格納するための柔軟性の高い仕組みを実現可能にするために使用され得るさまざまな方法を説明する。最後に、「例示的なシステム」と題するセクションにおいて、１つ以上の実施形態を実現するために利用され得る例示的なシステムを説明する。

本発明に関し、以下に後述するさまざまな実施形態についての概要を提供したので、ここでは、本発明に係る１つ以上の実施形態が実現され得る基盤となる例示的な動作環境を考慮する。

動作環境
図１Ａおよび図１Ｂは、１つ以上の実施形態に係る動作環境を示し、図１Ａおよび図１Ｂにおいては、当該動作環境はそれぞれ、１００ａおよび１００ｂとして一般化した形で示されている。図１Ａは、以下において後述するとおり、１つ以上のメタデータファイルの生成に関連して利用され得る例示的な動作環境を示す。図１Ａの環境は、「ビルド段階」の環境とみなされ得る。図１Ｂは、柔軟性の高い型システムを使用した型解決に関連して利用され得る例示的な動作環境を示す。図１Ｂの環境は、ランタイム時の環境とみなされ得る。本発明に係るいくつかの実施形態において、動作環境１００ａおよび１００ｂは、少なくともいくつかの同様のコンポーネントを有する。したがって、簡潔化のために、図１Ａおよび図１Ｂは一緒に説明される。図１Ａに関連づけられたコンポーネントが、「１ＸＸａ」との命名規則に従って命名されるコンポーネントとして特定される場合、図１Ｂに関連づけられる同様のコンポーネントは、「１ＸＸｂ」との命名規則に従って命名されるコンポーネントとして特定される。同様に、動作環境特有のコンポーネントは、単に「１ＸＸ」として特定される。

動作環境１００ａおよび１００ｂはそれぞれ、１つ以上のプロセッサ１０４ａ、１０４ｂを有するコンピューティング・デバイス１０２ａ、１０２ｂ、および１つ以上のコンピュータ読み取り可能な記憶媒体１０６ａ、１０６ｂを含む。コンピュータ読み取り可能な記憶媒体は、コンピューティング・デバイスに典型的に関連づけられる全ての形態の揮発性および不揮発性のメモリおよび／または記憶媒体を含み得る。そのような媒体の具体例を限定目的ではなく単に例示目的で挙げるならば、当該媒体は、ＲＯＭ、ＲＡＭ、フラッシュ・メモリ、ハードディスク、リムーバブル・メディア、等を含み得る。コンピューティング・デバイスの１つの特定の例が、図６において以下に示され説明される。

加えて、コンピューティング・デバイス１０２ａ、１０２ｂは、オペレーティング・システム（ＯＳ）１０８ａ、１０８ｂ、およびアプリケーション１１０ａ、１１０ｂを含む。オペレーティング・システム１０８ａ、１０８ｂは、コンピューティング・デバイス１０２ａ、１０２ｂのソフトウェア・リソースおよび／またはハードウェア・リソースを管理するように構成された機能を表す。これは、メモリ管理、ファイル管理、サービス、関数、リソース管理、周辺機器管理、等を含み得る。アプリケーション１１０ａ、１１０ｂは、コンピューティング・デバイス１０２ａ、１０２ｂ上で、典型的にはオペレーティング・システム１０８ａ、１０８ｂにより支援されて、実行するように構成されたソフトウェアを表す。アプリケーション１１０ａ、１１０ｂは、以下においてさらに説明されるように、オペレーティング・システム１０８ａ、１０８ｂの型システムと同一のおよび／または異なる型システムで実現され得る。

コンピューティング・デバイス１０２ａ、１０２ｂはまた、１つ以上のソフトウェア・インターフェース１１２ａ、１１２ｂを含み、１つ以上のソフトウェア・インターフェース１１２ａ、１１２ｂは、ソフトウェアおよび／またはアプリケーションによって提供される関数、サービス、データ、等への、プログラムに基づいたアクセス手段を表す。ソフトウェア・インターフェース１１２ａ、１１２ｂは、オペレーティング・システム１０８ａ、１０８ｂおよび／またはアプリケーション１１０ａ、１１０ｂへの、プログラムに基づいたアクセスを可能にし得る。たとえば、アプリケーション１１０ａ、１１０ｂは、ソフトウェア・インターフェース１１２ａ、１１２ｂを呼び出すことにより、オペレーティング・システム１０８ａ、１０８ｂによって提供される機能にアクセスし得る。いくつかの実施形態において、ソフトウェア・インターフェースを介して提供される型システムとは異なる型システムを使用するアプリケーション１１２ａ、１１２ｂは、以下においてさらに説明するように、型の相違をプログラムに基づいて解決し得る。

加えて、コンピューティング・デバイス１０２ａ、１０２ｂはまた、１つ以上のメタデータ・ファイル１１４ａ、１１４ｂを含み、１つ以上のメタデータ・ファイル１１４ａ、１１４ｂは、ソフトウェア・インターフェース１１２ａ、１１２ｂ、オペレーティング・システム１０８ａ、１０８ｂ、および／またはアプリケーション１１０ａ、１１０ｂに関連づけられた、入力パラメータの型、パラメータの呼び出し順序、インターフェース間の関係、等といった情報を含む、１つ以上の機械読み取り可能なファイルを表す。あるいは、または加えて、ソフトウェア・インターフェースは、コンピューティング・デバイス１０２ａ、１０２ｂに接続された周辺機器、たとえば、プリンタ、スキャナ、スマートフォン、等に関連づけられ得る。いくつかの実施形態において、メタデータ・ファイル１１４ａ、１１４ｂは、以下においてさらに説明されるように、任意の適切な手法でインターフェースを記述するように構成され得る。

コンピューティング・デバイス１０２ａはまた、マージ・モジュール１１６を含む。マージモジュール１１６は、１つ以上のメタデータ・ファイルを読み出し、ファイルの内容を分析し、再構成された内容を含む１つ以上の新たなメタデータ・ファイルを出力し得る機能を表す。本発明に係るいくつかの実施形態において、内容は、型記述に少なくとも部分的に基づいて再編成され得る。

コンピューティング・デバイス１０２ｂは、型解決モジュール１１８を含む。型解決モジュール１１８は、関連づけられた型データにアクセスするための要求を受信し、型解決情報の場所を特定するように構成された機能を表す。本発明に係るいくつかの実施形態において、型解決モジュール１１８は、情報が場所を変えても無関係に、ユーザ入力なしで型解決情報の場所を特定し得る。たとえば、型解決モジュール１１８は、以下においてさらに説明されるように、情報が第１のファイルから第２のファイルに移動した場合、ユーザ入力なしでインターフェース記述情報の場所を特定し得る。

コンピューティング・デバイス１０２ａ、１０２ｂの具体例を限定目的ではなく、例示目的で挙げるならば、これらは、例えば、デスクトップ型コンピュータ、ポータブル型コンピュータ、ノートブック型コンピュータ、携帯情報端末（ＰＤＡ）のようなハンドヘルド型コンピュータ、携帯電話、等といった任意の適切なコンピューティング・デバイスとして具現化され得る。

例示的な動作環境を説明したので、ここでは、場所のファイル名および／または場所とは無関係に型解決を可能にするように構成された型解決アーキテクチャの説明を考慮する。

型解決アーキテクチャ
プログラミング言語が技術的に進歩するにつれ、それらの能力も進歩する。たとえば、第１のプログラミング言語で書かれたアプリケーションが、第２のプログラミング言語で書かれたソフトウェアから呼び出され得る。本来、プログラミング言語は、異なる型システムを有する。したがって、異なる型システムの下に存在するソフトウェアを首尾よく呼び出すために、第１のプログラミング言語は、自身の型システムとは異なる型を解決するための技法を使用する。たとえば、プログラマは、型を変換するためのラッパー・コードを手作業で書くことが可能である。あるいは、型システムの定義がファイルに格納され、プログラムに基づいてアクセスされ得る。

型の定義を含むファイルにプログラムに基づいてアクセスすることは、機能および記述をアプリケーションがランタイムに決定することを可能にする。しかしながら、ファイルにアクセスするということは、どのファイルにアクセスべきであるかだけでなく、ファイルの格納場所も知っていなければならないことを暗に意味する。ファイルの内容が変わった場合および／またはファイルの格納場所が変わった場合、ファイルにアクセスしようと試みるアプリケーションは、適切に更新されない限り、場合によっては失敗し得る。これは時に、アプリケーションとファイルとの間の意図しない結合を生じさせる可能性がある。

本発明に係るさまざまな実施形態は、複数の型システム同士の間における型解決の仕組みを抽象化するための機能を実現する。型解決に関連づけられた情報は、プログラムに基づいてアクセス可能なファイルに格納され得る。いくつかの実施形態において、１つの型システムを使用するアプリケーションは、ファイルへのアクセスを通じて、もう１つの型システムを使用することにより動的に型解決を実行し得る。あるいは、または加えて、アプリケーションは、どのファイルにアクセスするのか、および／または、どこにファイルが存在するのかに関する知識を持つことなしに、ファイルにアクセスし得る。

図２を見ると、１つ以上の実施形態に係る例示的なアーキテクチャ２００が示されている。アーキテクチャ２００は、オペレーティング・システム２０２を含み、オペレーティングシステム２０２は、コンピューティング・デバイス上で実行するように構成され得る。簡潔化のためにオペレーティング・システム２０２の全体が示されていないことが理解されるべきである。オペレーティング・システム２０２は、コンピューティング・デバイスに関連づけられたリソースを管理するように構成された１つ以上のオペレーティング・システムコンポーネント２０４を含む。いくつかの実施形態において、オペレーティング・システムコンポーネント２０４は、リソースを管理することに関連づけられた１つ以上のサービスおよび／または特徴だけでなく、リソースへのプログラムに基づいたアクセスをも提供し得る。オペレーティング・システム・コンポーネント２０４はまた、オペレーティング・システム２０２に関連づけられた基本的な要素だけでなく、基本的な要素から構築された複合的な要素をも含み得る。この例はオペレーティング・システム２０２によって提供される機能を外部からアクセス可能とする（エクスポーズする）アーキテクチャを示しているが、このアーキテクチャが、特許請求の主題の精神から逸脱することなく、他の適切なタイプのアプリケーションによって提供される機能を外部からアクセス可能とするために適用され得ることが認められ、理解されるべきである。

本発明に係るいくつかの実施形態において、オペレーティング・システム・コンポーネント２０４は、ここではオペレーティング・システム・インターフェース２０６として示されている１つ以上のインターフェースを介して外部からアクセス可能とされ得る（エクスポーズされ得る）。このようなインターフェースは、任意の適切な形態のインターフェース、たとえば、アプリケーション・プログラミング・インターフェース（ＡＰＩ）とすることが可能である。アプリケーションは、以下においてさらに説明されるように、呼び出し中および／または実行中のオペレーティング・システム・インターフェース２０６により、オペレーティング・システム・コンポーネント２０４によって提供される機能にアクセスし得る。本実施形態に係るいくつかのケースにおいて、アプリケーションは、オペレーティング・システム・インターフェース２０６を記述するために使用される型システムとは異なる型システムを利用する。いくつかのケースにおいて、オペレーティング・システム・インターフェース２０６は、アプリケーション・バイナリ・インターフェース（ＡＢＩ）を含み得る。ＡＢＩは、機械により解釈実行可能な命令語レベルで、関数、方法、ＡＰＩ、等を呼び出すためのバイナリ・コントラクトを記述する。バイナリ・コントラクトは、関数に関連づけられた識別子または名前、関数を呼び出すために使用され得るシグネチャ、関数に受け渡されるパラメータの順序、および／または、パラメータに関連づけられたデータ型、等を含み得る。あるいは、または加えて、バイナリ・コントラクトは、型システムの少なくとも１つの型に関連づけられたエクスポーズ動作の挙動に関する定義および／または規則を含み得る。

オペレーティング・システム２０２はまた、さまざまなメタデータ２０８を含む。メタデータ２０８は、関連づけられたオペレーティング・システム・インターフェース２０６のさまざまな態様を記述する型解決情報、たとえば、バージョン情報、どの方法が利用可能か、インターフェースがどのパラメータを採用するか、パラメータのデータ型、パラメータを受け渡す順序、データ型の振る舞い、および／または解決情報、等を含み得る。本発明に係るいくつかの実施形態において、メタデータは、インターフェースに関連づけられた階層情報、たとえば、インターフェース間の関係を記述した、および／または、オブジェクト指向でインターフェースを記述した情報、を含み得る。メタデータはまた、クラスの記述、クラスの関連づけられた方法およびパラメータ、等を含み得る。本実施形態に係るいくつかのケースにおいて、メタデータは、抽象型システム（たとえば、特定のプログラミング言語と無関係の型システム）を使用してインターフェースを記述し得る。あるいは、または加えて、メタデータは、特定の型システム、たとえば、抽象型システムの記述を含み得る。すると、特定のプログラミング言語は、特定の型システム（たとえば、抽象型システム）の記述を特定のプログラミング言語にマッピングし得る。さらに、どのインターフェースが利用可能かを決定することを望むプログラマは、手作業で、および／またはプログラムに基づいて、各インターフェースの記述にアクセスすることができる。たとえば、どのインターフェースがオペレーティング・システム・コンポーネント２０４のアクセス手段として存在するか、インターフェースがどの型システムで記述されているか、どのようにそれらを呼び出すか、を決定するために、プログラマは、関連づけられたメタデータ２０８にアクセスし得る。

アーキテクチャ２００はまた、１つ以上のアプリケーション２１０を含む。アプリケーション２１０は、１つ以上のプログラミング言語、たとえば、ＨＴＭＬ、ＪａｖａＳｃｒｉｐｔ（登録商標）、Ｖｉｓｕａｌ Ｂａｓｉｃ、Ｃ＃、Ｃ＋＋、等から生成された１つ以上のアプリケーションを含み得る。いくつかの実施形態において、アプリケーション２１０は、オペレーティングシステムコンポーネントへの１つ以上の呼び出しを含む。いくつかのケースにおいて、アプリケーション２１０は、まず、どのインターフェースが利用可能かをプログラムに基づいて決定し、次に、決定されたインターフェースのうちの１つ以上への呼び出しを行うように構成され得る。いくつかのケースにおいて、アプリケーション２１０は、以下においてさらに説明するように、１つ以上の生成された言語投影モジュール２１２からの支援を受けて、インターフェースにアクセスする。

１つ以上の実施形態において、生成された言語投影モジュール２１２は、抽象型の定義を特定のプログラミング言語にマッピングする。任意の適切なプログラミング言語がマッピングされることができ、それらの例は上述したとおりである。いくつかの実施形態において、生成された言語投影モジュールは、各プログラミング言語毎に一意であり得る。本発明に係る他の実施形態において、生成された言語投影モジュールは、多目的な機能モジュールであり、複数のプログラミング言語によって利用され得る。上述したマッピングは、抽象型システムを使用して記述される現在および未来のインターフェースが、追加のプログラミング・ステートメント（たとえば、ラッパー関数）なしに特定のプログラミング言語にアクセスできるようにすることができる。上述したマッピングはさらに、特定のプログラミング言語にとってネイティブの手法で、当該特定のプログラミング言語がインターフェースを呼び出すことを可能にする。任意の適切なタイプの情報、たとえば、クラス、データ型、関数ポインタ、構造、等が、マッピングされ得る。

インターフェースの記述は、アプリケーションがどのようにインターフェースを呼び出すべきかを記述するだけでなく、インターフェースに関連づけられた型システムの挙動を記述するためにも使用され得る。記述の情報格納場所が特定されたことに応答して、アプリケーションは、どのようにインターフェースを呼び出すかを動的に決定し、アプリケーションとインターフェースとの間における型システムの相違を解決し得る。本発明に係るいくつかの実施形態において、異なる型システムを使用するアプリケーションは、型記述が存在する情報格納場所の知識なしに、プログラムに基づいて、インターフェースによって利用される型にアクセスし、その型の型解決を実行し得る。あるいは、または加えて、以下においてさらに説明するように、どのような方法で記述がグループ化されるかを特定することにより、自動的な型解決を実現可能にすることができる。

以下の実施例においては、ＪａｖａＳｃｒｉｐｔを使用してアプリケーションを書くプログラマがいると仮定する。この例はＪａｖａＳｃｒｉｐｔを使用した実現形態を説明するが、任意のプログラミング言語が特許請求の範囲に記載された技術思想から逸脱することなく使用され得ることが当業者にとって自明なものとして認められ理解されるべきである。外部の機能にアクセスするために、プログラマは、機能に関連づけられた名前空間および／または型を識別するように構成されたステートメントをソースコード中に含めることができる。たとえば、外部の型は、ソースコード内に以下のようにして含められ、および／または、以下のソースコードで記述され得る。
ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ．Ｆｏｏ．Ｂａｒ．Ｔｙｐｅ１

この特定の例において、Ｔｙｐｅ１は、アクセスされる機能を表現する。これは、任意の適切なタイプの機能であることができ、その例は、上述および後述されるとおりである。上記シンタックスは、Ｔｙｐｅ１の情報格納場所を特定するために横断的に走査することができる多層構造の名前空間階層を表現する。最も高い階層レベルにおいては、Ｔｙｐｅ１は、「ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ」として識別された名前空間に存在する。「ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ」内に「Ｆｏｏ」として識別された名前空間が存在する。同様に、「Ｆｏｏ」内には「Ｂａｒ」として識別された名前空間が存在し、「Ｂａｒ」にはＴｙｐｅ１が存在する。したがって、シンタックスは、Ｔｙｐｅ１の論理的な情報格納場所を識別するために使用され得る。しかしながら、Ｔｙｐｅ１の物理的な情報格納場所（たとえば、どのファイルにＴｙｐｅ１情報が存在するか、および／または、どのディレクトリにファイルが存在するか）は時間の経過に従って変わる可能性がある。従来、物理的な情報格納場所は、アプリケーション内においてパスおよびファイル名を（直接的または間接的に）ハード・コーディングすることによって決定されることができた。したがって、Ｔｙｐｅ１情報のファイル名および／またはパスが変わった場合、アプリケーションによって利用されるファイル名および／またはパスの任意の直接的または間接的な参照は、更新されるまで不適切であろう。さらに、直接的または間接的な参照が更新されるまで、アプリケーションは、場合によっては適切に機能することができなかった。

本発明に係るさまざまな実施形態は、型解決の仕組みを抽象化するための機能を実現する。たとえば、型は、関連づけられた型解決情報の情報格納場所に関する完全な知識なしに、アプリケーションにより、プログラムに基づいて解決されることができる。本発明に係るいくつかの実施形態において、型解決情報は、情報格納場所を表している新たな情報によって、解決情報を利用するアプリケーションを更新せずに、再配置され得る。アプリケーションは、どのファイル中に型解決情報が存在するかに関わらず、型解決情報の場所を特定するように構成されることが可能となる。

図３を見ると、本発明の１つ以上の実施形態に係る方法を実施するための一連の処理ステップを説明したフローチャートが示されている。当該方法は、任意の適切なハードウェア、ソフトウェア、ファームウェア、またはそれらの組み合わせによって実行され得る。本発明に係る少なくともいくつかの実施形態において、当該方法の実施態様は、１つ以上のコンピューティング・デバイス上で実行中の１つ以上の適切に構成されたソフトウェア・モジュール（たとえば、図１Ｂの型解決モジュール１１８）によって実現され得る。本発明に係るいくつかの実施形態において、当該方法は、ユーザによる介入なしに実行され得る。

ステップ３０２は、解決される型と一致するファイル名を有するファイルを探索する。これは、上述した複数のメタデータ・ファイルの探索を含み得る。上記シンタックスの例を参照すると、アプリケーションがＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ．Ｆｏｏ．Ｂａｒ．Ｔｙｐｅ１にアクセスすることに応答して、ステップ３０２は、「ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ．Ｆｏｏ．Ｂａｒ．Ｔｙｐｅ１」という名前を有するファイルを探索する。任意の適切なタイプの探索が実行され得る。たとえば、探索は、型とファイル名との間の完全一致、型とファイル名との間の部分一致、等を探すように構成され得る。あるいは、または加えて、探索は、１つのディレクトリ、複数のディレクトリ、および／またはサブディレクトリ、またはそれらの任意の組み合わせの中を探索するように構成され得る。

ステップ３０４は、ファイルが存在するかどうかを決定する。ファイルが存在するとの決定に応答して、ステップ３０６は、型が名前空間であることを示す情報を送信する。ファイルが存在しないとの決定に応答して、ステップ３０８は、解決される型に関連づけられた名前空間と一致するファイル名を探索する。いくつかのケースにおいて、これは、どの名前空間上を探索するかを決定するために、名前空間の階層を表す情報を含むストリングを操作することを含み得る。上述した例において、Ｔｙｐｅ１は、名前空間の階層において３階層下に配置されるものとして示されている。ストリングに対する操作は、型（たとえば、Ｔｙｐｅ１）を表す部分を削除し、名前空間の階層を表す部分を残すように実行され得る。ここで、ステップ３０８は、名前空間の階層「ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ．Ｆｏｏ．Ｂａｒ」に関連づけられた名前を探索するだろう。上記と同様に、この探索は、完全一致または部分一致の探索方法に従って探索を実行し、１つのディレクトリの中を探索し、さらにそのサブディレクトリの中を探索する、といった具合に構成され得る。

ステップ３１０は、ファイル名に関連づけられたファイルが存在するかどうかを決定する。ファイルが存在するとの決定に応答して、ステップ３１２は、型に関連づけられた情報のためにファイルを処理する。

ステップ３１４は、型に関連づけられた情報がファイル内に配置されているかどうかを決定する。型に関連づけられた情報がファイル内にあるとの決定に応答して、ステップ３１６は、情報を戻す。たとえば、情報は、呼び出しているプログラムに戻され得る。しかしながら、型に関連づけられた情報がファイル内にないとの決定に応答して、処理はステップ３１８に進む。

ステップ３１８においては、より高い階層レベルの名前空間と一致するファイル名が探索される。ステップ３１８におけるこの探索動作は、たとえば、ステップ３１０の実行時におけるファイルが存在しないとの決定に応答する形で、または、ステップ３１４の実行時に、型に関連づけられた情報の格納場所をファイル内において特定することができないことに応答する形で実行することが可能である。より高い階層レベルの名前空間は、任意の適切な手法で決定され得る。たとえば、上記の例では、ストリングが、名前空間階層における１つ上のレベル（たとえば、「ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ．Ｆｏｏ」）を反映させるようにさらに操作され得る。ステップ３１８は、より高い階層レベルの名前空間を決定し、関連づけられた名前を有するファイルを探索する。

ステップ３２０は、ファイル名に関連づけられたファイルが存在するかどうかを決定する。ステップ３１０のケースのように、ファイルが存在すると決定された場合、処理は、ステップ３１２、３１４、および／または３１６に進み、ファイルが、関連づけられた型情報のために処理される。

ファイルが存在しないとの決定に応答して、ステップ３２２は、さらに別の名前空間階層レベルが存在するかどうかを決定する。これは、任意の適切な手法で決定され得る。たとえば、レベル分離文字についてストリングを探索することができる。上記の例では、シンタックス「．」が、名前空間階層のレベルを区別する。

さらに別の名前空間階層レベルが存在するとの決定に応答して、上述した処理が繰り返され、処理はステップ３１８に戻り、新たに決定された名前空間を有するファイルを探索する。ステップ３１８、３２０、および３２２は、適切なファイルが見つかるまで、または、名前空間階層の最上部に到達し、最上部が探索されるまで、繰り返し実行される。さらに別の名前空間階層レベルが存在しないとの決定に応答して、ステップ３２４はエラーを戻す。これは、例外処理を実行すること、ポップアップ・ダイアログ・ボックスを表示すること、等を含み得る。

上述した方法の使用により、複数のファイルおよび／または情報格納場所が、型解決情報について探索され得る。説明したように、型の探索は、階層名前空間情報に少なくとも部分的に基づき得る。図３は、より低い名前空間階層レベル（たとえば、「ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ．Ｆｏｏ．Ｂａｒ．Ｔｙｐｅ１」）から始まり、型の格納場所が特定されるか又は最上部の名前空間階層レベル（たとえば、「ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ」）に到達するまで、名前空間の各階層レベルを上に向かって横断的に走査するように実行される型の探索動作を説明する。しかしながら、この探索動作は、任意の適切な順序で実行され得る。本発明に係るいくつかの実施形態では、型の探索動作は、より高い名前空間階層レベル（たとえば、「ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ」）から始まり、型の格納場所が特定されるか最下部の名前空間階層レベル（たとえば、「ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ．Ｆｏｏ．Ｂａｒ．Ｔｙｐｅ１」）に到達するまで、名前空間の各階層レベルを下に向かって横断的に走査し得る。名前空間階層上の探索は、型解決情報がどこに存在し得るかを抽象化することができ、さらに、型解決情報にアクセスするアプリケーションに影響を及ぼさずに型解決情報の情報格納場所を変更することを可能にする。

場所のファイル名および／または場所とは無関係に型解決を可能にするように構成された型解決アーキテクチャが考慮されたので、ここでは、１つ以上の実施形態に係るフレキシブルな型記述の格納の説明を考慮する。

型記述の格納
メタデータ・ファイルが、ソフトウェア・インターフェースのさまざまな態様を記述するために使用され得る。上述したように、メタデータ・ファイルは、クラス階層、抽象型システム、関連づけられた方法、プロパティ、およびイベント、等によってインターフェースを記述する情報を含み得る。本実施形態に係るいくつかのケースにおいて、関連づけられた情報は、複数のファイル内に存在し得る。たとえば、異なるメタデータファイルが、同一の名前空間に関連する情報を含み得る。複数のメタデータ・ファイルは、メタデータ・ファイルの開発者に高い柔軟性を与え得る一方で、それは時に、メタデータ・ファイルをユーザが探索する際の妨げとなり得る。以下の例では、各名前空間が、それ独自の関連づけられたメタデータ・ファイルを有する例を考慮する。分割の観点からは、各名前空間のための別個のファイルは、名前空間に対する変更を、関連づけられたファイルに分離することができる。しかしながら、探索の観点からは、情報について複数のファイルを探索しなくてはならないことは、ランタイムでの探索時の性能を低下させ得る。さらに、知識の観点からは、何の情報が何のファイルの中にあるかの追跡を維持することは、ファイル数が増加すると複雑化し得る。

本発明に係るさまざまな実施形態は、型解決情報が存在するファイル名およびファイル格納場所の予備知識なしの型解決を実現可能にする。複数の入力ファイルから成るファイル群の内容が分析され、少なくとも部分的には合成規則に基づいて分割され得る。複数の出力ファイルから成るファイル群を生成することができ、分割された内容を含むように構成される。出力ファイルは、内容がどこに存在するかの予備知識なしに内容の格納場所を特定することを可能にし得る。

例として、図４を見ると、１つ以上の実施形態に係る、記述言語ファイル、メタデータ・ファイル、およびマージ・モジュール間の関係が示されている。本発明に係る少なくともいくつかの実施形態において、この関係図に示されたモジュールは、ソフトウェア、ハードウェア、またはそれらの任意の組み合わせ、たとえば、図１Ａのマージ・モジュール１１６として実現され得る。

例示され説明された実施形態において、Ｆｏｏ．ｉｄｌ ４０２は、１つ以上のインターフェースを記述するように構成された記述言語ファイルを表す。本発明に係るいくつかの実施形態において、インターフェースは、図１のオペレーティング・システム・インターフェース１０８および／またはアプリケーション１１０といった、オペレーティング・システムおよび／またはアプリケーションに関連づけられ得る。記述言語ファイルは、任意の適切な記述、マーク付け言語、および／またはシンタックスを使用して、たとえば、インターフェース定義言語（ＩＤＬ）、拡張可能なマーク付け言語（ＸＭＬ）、等を用いて、インターフェースを記述し得る。この特定の例において、Ｆｏｏ．ｉｄｌは、ＩＤＬファイルを表す。

Ｆｏｏ．ｉｄｌ ４０２は、３つの型の記述、Ｔｙｐｅ Ｆｏｏ．Ｂａｒ．Ｔｙｐｅ１ ４０４、Ｔｙｐｅ Ｆｏｏ．Ｂａｒ．Ｔｙｐｅ２ ４０６、およびＴｙｐｅ Ｆｏｏ．Ｂａｒ．Ｔｙｐｅ３ ４０８を含む。３つのエントリを用いて説明するが、任意の適切な数の記述、ならびに型の記述が、特許請求の範囲に記載された発明の技術思想から逸脱することなく、Ｆｏｏ．ｉｄｌ ４０２に含まれ得ることが認められ理解されるべきである。たとえば、型は、クラス、インターフェース、方法、プロパティ、イベント、等の記述を含み得る。この例では、型４０４、４０６、および４０８は、「Ｆｏｏ．Ｂａｒ」の階層名前空間に含まれるものとして記述される。

図４はまた、第２の記述言語ファイル、Ｂａｒ．ｉｄｌ ４１０を示す。Ｆｏｏ．ｉｄｌ ４０２と同様に、Ｂａｒ．ｉｄｌ ４１０は、３つの型、Ｔｙｐｅ Ｆｏｏ．Ｂａｒ．Ｔｙｐｅ４ ４１２、Ｔｙｐｅ Ｆｏｏ．Ｑｕｕｘ．Ｔｙｐｅ１ ４１４、およびＴｙｐｅ Ｆｏｏ．Ｑｕｕｘ．Ｔｙｐｅ２ ４１６を含む記述言語ファイルを表す。型４１２、４１４、および４１６のシンタックスを参照すると、Ｂａｒ．ｉｄｌ ４１０は、名前空間「Ｆｏｏ．Ｂａｒ」における少なくとも１つの型、および、名前空間「Ｆｏｏ．Ｑｕｕｘ」における少なくとも２つの型を含む。

Ｆｏｏ．ｍｅｔａｄａｔａ ４１８は、Ｆｏｏ．ｉｄｌ ４０２に少なくとも部分的に基づいた機械読み取り可能なメタデータ・ファイルを表す。説明は省略するが、本発明に係るいくつかの実施形態において、Ｆｏｏ．ｍｅｔａｄａｔａ ４１８は、Ｆｏｏ．ｉｄｌ ４０２からコンパイラによって生成され得る。Ｆｏｏ．ｉｄｌ ４０２と同様に、Ｆｏｏ．ｍｅｔａｄａｔａ ４１８は、メタデータファイルにネイティブなフォーマットの型の記述、Ｆｏｏ．Ｂａｒ．Ｔｙｐｅ１ ４２０、Ｆｏｏ．Ｂａｒ．Ｔｙｐｅ２ ４２２、およびＦｏｏ．Ｂａｒ．Ｔｙｐｅ３ ４２４を含む。Ｂａｒ．ｍｅｔａｄａｔａ ４２６もまた、Ｂａｒ．ｉｄｌ ４１０に少なくとも部分的に基づいた機械読み取り可能なメタデータ・ファイルを表す。Ｆｏｏ．ｍｅｔａｄａｔａ ４１８のケースのように、Ｂａｒ．ｍｅｔａｄａｔａ ４２６は、型の記述、Ｆｏｏ．Ｂａｒ．Ｔｙｐｅ４ ４２８、Ｆｏｏ．Ｑｕｕｘ．Ｔｙｐｅ１ ４３０、およびＦｏｏ．Ｑｕｕｘ．Ｔｙｐｅ３ ４３２を含む。

図４に含まれるのは、マージ・モジュール４３４である。マージ・モジュール４３４は、１つ以上の入力ファイルを受け取ると、判定基準および／または規則のセットに基づいて１つ以上の出力ファイルを生成し得る。たとえば、入力ファイルを探索する入力ディレクトリ、出力ファイルを置く出力ディレクトリ、適用する検査のレベル、どの名前空間階層レベルで統合および／または分割するか、どのようにして出力ファイルに命名するか、出力ファイルをいくつ生成するか、どの深度でメタデータ・ファイルが生成されるべきか、等を指定する入力コマンドおよび／または規則が、マージ・モジュール４３４に適用され得る。判定基準および／または規則は、任意の適切な手法、たとえば、１つ以上の規則を含むコマンド・ラインおよび／または「ｍａｋｅｆｉｌｅ」によって、マージ・モジュール４３４に与えられ得る。

この例では、Ｆｏｏ．ｍｅｔａｄａｔａ ４１８およびＢａｒ．ｍｅｔａｄａｔａ ４２６が、マージ・モジュール４３４への入力である。マージ・モジュール４３４は、入力ファイルをオペランド解析し、指示どおりに出力ファイルを生成する。ここで、マージ・モジュール４３４は、２つの出力ファイル、Ｆｏｏ．Ｂａｒ．ｍｅｔａｄａｔａ ４３６およびＦｏｏ．Ｑｕｕｘ．ｍｅｔａｄａｔａ ４３８を生成する。Ｆｏｏ．Ｂａｒ．ｍｅｔａｄａｔａ ４３６は、「Ｆｏｏ．Ｂａｒ」の名前空間に関連する型（たとえば、Ｆｏｏ．Ｂａｒ．Ｔｙｐｅ１ ４４０、Ｆｏｏ．Ｂａｒ．Ｔｙｐｅ２ ４４２、Ｆｏｏ．Ｂａｒ．Ｔｙｐｅ３ ４４４、およびＦｏｏ．Ｂａｒ．Ｔｙｐｅ４ ４４６）を含む。同様に、Ｆｏｏ．Ｑｕｕｘ．ｍｅｔａｄａｔａ ４３８は、「Ｆｏｏ．Ｑｕｕｘ」の名前空間に関連する型（たとえば、Ｆｏｏ．Ｑｕｕｘ．Ｔｙｐｅ１ ４４８、Ｆｏｏ．Ｑｕｕｘ．Ｔｙｐｅ２ ４５０）を含む。上記の例におけるように、Ｆｏｏ．Ｂａｒ．ｍｅｔａｄａｔａ ４３６およびＦｏｏ．Ｑｕｕｘ．ｍｅｔａｄａｔａ ４３８は、場合によっては関連づけられた入力ファイルから再編成および／または再グループ化されたデータを含む、機械読み取り可能なメタデータ・ファイルを表す。したがって、マージ・モジュール４３４は、複数のファイルからの内容を分析し、判定基準のセットに従って内容を再構築し得る。

本発明に係るいくつかの実施形態において、ファイルの命名規則が、抽象型解決を可能にするために利用され得る。たとえば、名前空間階層が命名規則として使用され得る。図４において、ファイルＦｏｏ．Ｂａｒ．ｍｅｔａｄａｔａ ４３６およびＦｏｏ．Ｑｕｕｘ．ｍｅｔａｄａｔａ ４３８は、それらのファイル名に、関連づけられた名前空間階層（たとえば、それぞれ、「Ｆｏｏ．Ｂａｒ」および「Ｆｏｏ．Ｑｕｕｘ」）を含む。この命令規則を利用することにより、型情報は、特定のファイル名ではなく、それに関連づけられた名前空間に基づいて、探索されることが可能である。あるいは、または加えて、出力ファイルは、複数の名前空間階層レベルのデータを含み得る。図４において、Ｆｏｏ．Ｂａｒ．ｍｅｔａｄａｔａ ４３６は、「Ｆｏｏ．Ｂａｒ」の名前空間にデータを含むものとして示されている。しかしながら、Ｆｏｏ．Ｂａｒ．ｍｅｔａｄａｔａ ４３６はまた、「Ｆｏｏ．Ｂａｒ．Ｌｅｖｅｌ１．Ｌｅｖｅｌ２．Ｌｅｖｅｌ３」という名前空間階層レベルに存在する型情報を含むように構成され得る。したがって、命名規則は、ファイル内に含まれ得る最も高いレベルの名前空間を示す。

加えて、適切な型を格納している格納場所が特定されるまで、図３において説明されたような探索アルゴリズムが、異なる階層レベルの名前空間（および関連づけられたファイル）を横断的に走査するために用いられ得る。同一の名前空間階層レベルにおける全ての型情報を同一のファイル内に存在するように構成することにより、特定のレベルに関連づけられた情報は、情報を利用するアプリケーションに影響を及ぼさずにファイルからファイルへ移動させられることが可能となる。名前空間階層に関連づけられた情報は、任意の適切な手法で分割され得る。たとえば、複数の階層レベルが同一のファイル内に存在する（たとえば、Ｆｏｏ．Ｂａｒ、Ｆｏｏ．Ｂａｒ．Ｌｅｖｅｌ１、およびＦｏｏ．Ｂａｒ．Ｌｅｖｅｌ２がすべて、「Ｆｏｏ．Ｂａｒ．ｍｅｔａｄａｔａ」と命名されたファイル内に存在する）ようにすることも可能であるし、または、各ファイルがそれ独自の関連づけられたファイルを有する（たとえば、Ｆｏｏ．Ｂａｒのレベルにおける情報が、「Ｆｏｏ．Ｂａｒ．ｍｅａｔａｄａｔａ」内に存在し、Ｆｏｏ．Ｂａｒ．Ｌｅｖｅｌ１における情報が、「Ｆｏｏ．Ｂａｒ．Ｌｅｖｅｌ１．ｍｅｔａｄａｔａ」ファイル内に存在する）ようにすることも可能である、といった具合である。情報がそれに関連づけられた名前空間階層に従って置かれる場合、型解決は、特定のファイル名への依存を除くことによって、抽象化され得る。

ここで図５を見ると、本発明の１つ以上の実施形態に係る方法を実施するための一連の処理ステップを説明したフローチャートが示されている。この方法は、任意の適切なハードウェア、ソフトウェア、ファームウェア、またはそれらの組み合わせによって実行され得る。本発明に係る少なくともいくつかの実施形態において、この方法の実施態様は、図１Ａのマージ・モジュール１１６のような、１つ以上のコンピューティング・デバイス上で実行中の、適切に構成された１つ以上のソフトウェア・モジュールによって実現され得る。

ステップ５０２は、１つ以上の出力ファイルを生成することに関連づけられた１つ以上の入力判定基準を受信する。本発明に係るいくつかの実施形態において、当該入力判定基準は、情報をどのようにして１つ以上の出力ファイルへと分割するかを指定する規則を含み得る。たとえば、当該入力判定基準は、出力ファイルに一緒にグループ化する１つ以上の名前空間階層レベルを指定し得る。あるいは、または加えて、当該入力判定基準は、たとえば、どのファイルおよび／またはどのディレクトリから情報を引き出すかを指定することによって、どこで情報を見つけるかを記述し得る。

１つ以上の入力判定基準を受信することに応答して、ステップ５０４は、１つ以上のソフトウェア・インターフェースと関連づけられた情報を含む１つ以上の入力ファイルを受信する。当該情報は、抽象型システムを使用するソフトウェア・インターフェースの記述、オブジェクト指向の関連づけ、方法、プロパティ、関数ポインタ、入力および／または出力パラメータ、型システム情報、等といった、任意の適切なタイプの情報とすることが可能である。本発明に係る実施形態において、型情報は、名前空間の階層情報を含み得る。

１つ以上の入力ファイルを受信することに応答して、ステップ５０６は、１つ以上の入力判定基準に少なくとも部分的に基づいて情報を分析する。これは、どの名前空間階層の型情報が各ファイル内に存在するかを決定するために入力ファイルを分析することを含み得る。

情報を分析することに応答して、ステップ５０８は、当該情報を含む少なくとも１つの出力ファイルを生成する。本発明に係るいくつかの実施形態において、当該出力ファイルは、上述した入力判定基準に少なくとも部分的に基づいて異なるファイルに再分割された情報を含み得る。当該出力ファイルは、任意の適切な手法で構成されることができ、そのような手法の例は、上述されたとおりである。たとえば、当該出力ファイルは、メタデータ・ファイルに含まれる名前空間階層に基づいた命名規則を用いて命名されたメタデータ・ファイルとして構成され得る。あるいは、または加えて、当該出力ファイルは、複数のレベルの名前空間階層を含むように構成され得る。名前空間階層情報を出力ファイル中に一緒にグループ化することによって、アプリケーションは、特定のファイル名ではなく、名前空間階層レベルに基づいて情報を探索することができる。これは、アプリケーションに影響を及ぼさない形で情報の分割を柔軟に実行することを可能にする。アプリケーションがどの名前空間階層レベルに特定の型が存在するのかを知っている限り、どのように名前空間階層レベルがグループ化されるかに関わらず、関連づけられた型情報の情報格納場所が出力ファイル中で特定され得る。

柔軟性の高い型記述情報の格納方法を説明したので、以下の説明においては、本発明の１つ以上の実施形態に係る例示的なシステムの説明を考慮する。

例示的なシステム
図６は、上述したさまざまな実施形態を実現するために使用され得る例示的なコンピューティングデバイス６００を示す。コンピューティングデバイス６００は、たとえば、図１Ａおよび図１Ｂのコンピューティングデバイス１０２ａおよび／または１０２ｂ、または任意の他の適切なコンピューティングデバイスとすることが可能である。

コンピューティング・デバイス６００は、１つ以上のプロセッサまたは処理ユニット６０２、１つ以上のメモリおよび／またはストレージ・コンポーネント６０４、１つ以上の入力／出力（Ｉ／Ｏ）デバイス６０６、および、さまざまなコンポーネントおよびデバイスに互いに通信することを可能にさせるバス６０８を含む。バス６０８は、メモリ・バスまたはメモリ・コントローラ、周辺機器用バス、アクセラレイティッド・グラフィックス・ポート、および、さまざまなバス・アーキテクチャのうちのいずれかを使用するプロセッサまたはローカル・バスを含む、いくつかのタイプのバス構造のうちのいずれかの１つ以上を表す。バス６０８は、有線および／または無線バスを含み得る。

メモリ／ストレージ・コンポーネント６０４は、１つ以上のコンピュータ・ハードウェア記憶媒体を表す。コンポーネント６０４は、揮発性媒体（たとえば、ランダム・アクセス・メモリ（ＲＡＭ））および／または不揮発性媒体（たとえば、読み出し専用メモリ（ＲＯＭ）、フラッシュ・メモリ、光学ディスク、磁気ディスク、等）を含み得る。コンポーネント６０４は、固定媒体（たとえば、ＲＡＭ、ＲＯＭ、固定ハード・ドライブ、等）だけでなく、取り外し可能な媒体（たとえば、フラッシュ・メモリ・ドライブ、リムーバブル・ハードドライブ、光学ディスク、等）を含み得る。

１つ以上の入力／出力デバイス６０６は、ユーザによるコンピューティング・デバイス６００へのコマンドおよび情報の入力を可能にし、また、ユーザおよび／または他のコンポーネントまたはデバイスへの情報の提示を可能にする。入力デバイスの例は、キーボード、カーソル操作用デバイス（たとえば、マウス）、マイクロフォン、スキャナ、等を含む。出力デバイスの例は、ディスプレイ装置（たとえば、モニタまたはプロジェクタ）、スピーカー、プリンタ、ネットワーク・カード、等を含む。

さまざまな技法が、ソフトウェアまたはプログラム・モジュールの一般的なコンテキストで、本明細書において説明され得る。一般的に、ソフトウェアは、特定のタスクを実行するか、または特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造、等を含む。これらのモジュールおよび技法の実現は、何らかの形態のコンピュータ読み取り可能な媒体上に記憶されるか、またはそのような媒体によって伝送され得る。コンピュータ読み取り可能な媒体は、コンピューティング・デバイスによってアクセス可能な、任意の利用可能な単数の媒体または複数の媒体とすることが可能である。限定ではなく例として、コンピュータ読み取り可能な媒体は、「コンピュータ読み取り可能な記憶媒体」を備え得る。

「コンピュータ読み取り可能な記憶媒体」は、コンピュータ読み取り可能な命令、データ構造、プログラムモジュール、または他のデータ、といった情報の記憶のための、任意の方法または技術において実現される、揮発性および不揮発性の、取り外し可能および取り外し不可能な、ハードウェア媒体を含む。コンピュータ読み取り可能なハードウェア記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリ、または他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、または他の光学ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、または他の磁気ストレージデバイス、または、所望の情報を記憶するために使用可能かつコンピュータによってアクセス可能な任意の他の媒体を含むが、これらに限定されない。

結論
さまざまな実施形態は、複数の型システム間の型解決を抽象化するための能力を提供する。少なくとも１つの型が、プログラムに基づいてアクセス可能な１つ以上のファイルに記述され得る。いくつかの実施形態において、異なる型システムを使用するアプリケーションは、型の記述が存在する場所の知識なしに、少なくとも１つの型システムの型に、プログラムに基づいてアクセスし、その型を解決することができる。あるいは、または加えて、プログラムに基づいてアクセス可能な１つ以上のファイルに含まれる型の記述は分析され、型の記述に少なくとも部分的に基づいて、プログラムに基づいてアクセス可能な１つ以上の新たなファイルへと再構築されることができる。

主題は、構造上の特徴および／または方法の動作特有の表現で説明されたが、添付の請求項において定義される主題は、必ずしも上述した特定の特徴または動作に限定されるものではないことが理解されるべきである。そうではなく、上述した特定の特徴および動作は、請求項を実現する例示的な形態として開示されている。

Claims (10)

1. コンピューティング装置上で実行中のプロセッサ実行可能なソフトウェア・モジュールによって実行され、コンピュータにより実現される方法であって、
   型解決情報の格納位置を特定しようとするアプリケーションからの要求に応じて、前記型解決情報に関連づけられた第１のファイルを複数のファイルの中から探索するステップであって、前記型解決情報は、特定の型について前記アプリケーションの型システムとその他の型システムとの間における相違を型解決するための情報である、ステップと、
   前記第１のファイルが存在するとの決定に応答して、前記型が名前空間を表す型であることを示す情報を送信するステップと、
   前記第１のファイルが存在しないとの決定に応答して、前記型に関連づけられた第１の名前空間レベル階層と一致するファイル名に関連づけられたファイルを前記複数のファイルの中から探索するステップと、
   前記型に関連づけられた第１の名前空間レベル階層と一致するファイル名が存在するとの決定に応答して、前記型に関連づけられた情報に関して前記ファイル名に関連づけられたファイルを処理するステップと、
   前記型に関連づけられた前記第１の名前空間レベル階層と一致する前記ファイル名が存在しないとの決定に応答して、前記型に関連づけられたさらに別の名前空間階層レベルが存在するかどうかを決定するステップと、
   さらに別の名前空間階層レベルが存在するとの決定に応答して、前記さらに別の名前空間階層レベルに関連づけられたファイル名を前記複数のファイルの中から探索するステップと
   を備える方法。
2. 前記第１のファイルを複数のファイルの中から前記探索するステップはさらに、前記型に関連づけられた名前と一致するファイル名を有するファイルを前記複数のファイルの中から探索する処理動作を備える、請求項１に記載のコンピュータにより実現される方法。
3. 前記第１のファイルを複数のファイルの中から前記探索するステップはさらに、前記型が存在する情報格納場所に関する知識なしに、前記第１のファイルを探索する処理動作を備える、請求項２に記載のコンピュータにより実現される方法。
4. ユーザの介入なしに実行される、請求項１に記載のコンピュータにより実現される方法。
5. 前記複数のファイルは、メタデータ・ファイルを備え、個々の前記メタデータ・ファイルは、オペレーティング・システムのソフトウェア・インターフェースに関連づけられた記述を含む、請求項１に記載のコンピュータにより実現される方法。
6. 前記メタデータ・ファイルは、特定のプログラミング言語とは無関係に前記型を記述するように構成される、請求項５に記載のコンピュータにより実現される方法。
7. コンピュータ読み取り可能な命令コードを備える１つ以上のコンピュータ読み取り可能なハードウェア記憶媒体であって、前記命令コードは、実行された際に、型解決モジュールの機能を実現し、前記型解決モジュールは、コンピューティング装置上でプロセッサ実行可能なソフトウェア・モジュールとして実装され、ユーザの介入なしに：
   型解決情報の格納位置を特定しようとするアプリケーションからの要求に応じて、前記アプリケーションの型システムに関連づけられた特定の型の名前空間と一致するファイル名を有するファイルについて１つ以上のメタデータ・ファイルを探索し；
   前記ファイルが存在するとの決定に応答して、前記特定の型に関連づけられた情報に関して前記ファイルを処理し；
   前記ファイルが存在しないとの決定に応答して：
   前記特定の型に関連づけられたさらに別の名前空間階層レベルが存在するかどうかを決定する処理動作；および、
   さらに別の名前空間階層レベルが存在するとの決定に応答して、前記さらに別の名前空間階層レベルと一致するファイル名を有するファイルについて前記１つ以上のメタデータ・ファイルを探索する処理動作；
   を少なくとも一度実行するように構成され、前記少なくとも一度実行する動作は、
   前記別の名前空間階層レベルと一致するファイル名を有する前記ファイルが存在すると決定されたこと、または
   別の名前空間階層レベルが存在しないと決定されたこと、
   に応答して、少なくとも実行を一旦終了することを特徴とするモジュールであり、
   前記型解決情報は、特定の型について前記アプリケーションの型システムとその他の型システムとの間における相違を型解決するための情報である、１つ以上のコンピュータ読み取り可能な
   ハードウェア記憶媒体。
8. 前記別の名前空間階層レベルと一致するファイル名を有するファイルについて前記１つ以上のメタデータ・ファイルを探索する処理動作は、前記名前空間階層レベルと一致する少なくとも部分的なファイル名の探索動作を備える、請求項７に記載の１つ以上のコンピュータ読み取り可能なハードウェア記憶媒体。
9. 前記型システムに関連づけられた型は、オペレーティング・システムに関連づけられたアプリケーション・プログラミング・インターフェース（ＡＰＩ）を備える、請求項７に記載の１つ以上のコンピュータ読み取り可能なハードウェア記憶媒体。
10. 前記型システムに関連づけられた型の名前空間と一致するファイル名を有するファイルについて１つ以上のメタデータ・ファイルを探索する処理動作はさらに、前記型が存在する情報格納場所の知識なしで実行される探索動作を備える、請求項７に記載の１つ以上のコンピュータ読み取り可能なハードウェア記憶媒体。

Images