JP2014525623A - オペレーティングシステムのネイティブプログラミングインターフェイスの他のプログラミング言語の中への投射 - Google Patents

Abstract

オペレーティングシステムのアプリケーションプログラミングインターフェイスに関する情報は、既知のフォーマットで既知のロケーションに保管される。この情報はオペレーティングシステムによって示されるＡＰＩを完全に記述しており、ＡＰＩメタデータファイルの中に保管されている。言語コンパイラー又はインタープリターは、このＡＰＩ情報を使用して、対象言語においてネイティブシステムＡＰＩの自然でよく知られた表現を作成する。言語コンパイラー又はインタープリターは、コンパイル時及び/又は実行時にＡＰＩ情報を読み出すことができる。メタデータが使用され、アプリケーションはＡＰＩにおける名前付きエレメントを参照することができる。投射が行われ、メタデータを使用し投射が行われ、ＡＰＩにおける名前付きエレメントを対象言語における名前付きエレメントにマップし、対象表現とネイティブオペレーティングシステム表現との間でこうしたエレメントのデータを変換するラッパーを規定する。

Description

本発明は、ネイティブシステムＡＰＩを他のプログラミング言語の中へ投射することに関する。

オペレーティングシステムは、典型的にいくつかのプログラミングインターフェイスを有しており、アプリケーションはオペレーティングシステムによってサポートされている機能性にアクセスすることができる。こうしたＡＰＩ（アプリケーションプログラミングインターフェイス）は、典型的にコンピュータープログラミング言語における名前付きファイルまたはオブジェクトを使用してオペレーティングシステムによって規定されている。例えば、Ｃプログラミング言語は、"interface.h"といった名前のヘッダーファイルを使用する。同様に、"P/Invoke"と呼ばれるＣ＃メカニズムにおいて、オペレーティングシステムのＡＰＩにアクセスするためにシグネチャー（ｓｉｇｎａｔｕｒｅ）が使用されている。オペレーティングシステムのＡＰＩを使用するコンピュータープログラムを書く人は、典型的にプログラムの中の名前付きＡＰＩファイル又はオブジェクトを参照し、または、プログラミング言語によって提供される別のメカニズムを使用する。プログラムは、例えば、そのＡＰＩによって規定されたファンクションに対するコール（ｃａｌｌ）を含んでいる。そのＡＰＩによって使用されている構文においてである。

こうしたやり方で規定されたＡＰＩは、それらが書き込まれた言語以外の言語によっては直接的にアクセスすることができない。他の言語の中に書き込まれたプログラムにアクセスできるようにするために、ＡＰＩはラップ（”ｗｒａｐｐｅｄ”）される。このラップは、典型的にはＡＰＩごと及び言語ごとに行われる必要があり、対象言語とＡＰＩとオペレーティングシステムの深い理解を要するものである。従って、多くのオペレーティングシステムのＡＰＩは利用できない。

本概要は、以降の詳細な説明でより詳しく記述される本発明の概念について、簡素化された形式において代表的な概念の選択を紹介するものである。本概要は、特許請求された技術的事項の主要な特徴または本質的な特徴を特定することを意図するものではない。また、特許請求された技術的事項の範囲を限定するために使用されることを意図するものではない。

オペレーティングシステムが作成されるときは、ＡＰＩに関する情報が生成され、オペレーティングシステムの中の既知のロケーションに既知のフォーマットにおいて保管される。この情報は、オペレーティングシステムによって公開された全てのＡＰＩを完全に記述するものである。これは、これらに限定されるわけではないが、ＡＰＩ、種々のタイプの名前付きエレメントに関する情報を含んでいる。ベーシックタイプ、列挙型、デリゲート（ｄｅｌｅｇａｔｅ）、インターフェイス、クラス、メソッド、プロパティ、および、イベントといったものである。

言語コンパイラー又はインタープリターは、このＡＰＩ情報を使用して、対象言語におけるネイティブシステム（ｎａｔｉｖｅ ｓｙｓｔｅｍ）ＡＰＩの自然でよく知られた表現を作成する。この表現は、言語によって変わるものである（自然でよく知られたものは言語ごとに変わるからである）。言語コンパイラー又はインタープリターは、コンパイル時及び/又は実行時のＡＰＩ情報、対象の言語に対して最も好適なあらゆるものを読み出すことができる。例えば、Ｃ＋＋のような静的コンパイル言語は、純粋にコンパイル時においてメタデータを使用し、一方で、Ｐｙｔｈｏｎ又はＪａｖａＳｃｒｉｐｔ（登録商標）のような動的言語は、純粋に実行時においてメタデータを使用する。.ＮＥＴ又はＪａｖａ（登録商標）のような環境は、コンパイル時と実行時の両方においてメタデータを使用するであろう。メタデータは、アプリケーションがＡＰＩにおける名前付きエレメントを参照することができるように使用される。メタデータを使用する投射（ｐｒｏｊｅｃｔｉｏｎ）が作成され、ＡＰＩにおける名前付きエレメントを対象言語における名前付きエレメントに対してマップし、対象表現とネイティブオペレーティングシステム表現との間のこうしたデータを変換するラッパー（ｗｒａｐｐｅｒ）を規定する。

従って、一つの態様において、オペレーティングシステムのアプリケーションプログラミングインターフェイスを記述するメタデータはメモリーの中に保管される。プログラミング言語におけるプログラムの中で名前付けされた指標が与えられれば、アプリケーションプログラミングインターフェイスのうち一つのエレメントを参照して、名前付けされたエレメントは、メタデータを使用してプログラミング言語の中に投射される。投射は、プログラムのコンパイル又はインタープリテーション（ｉｎｔｅｒｐｒｅｔａｔｉｏｎ）の最中に生じ得る。投射は、プログラミング言語において一つまたはそれ以上のエレメントを作成するコードを作成すること、および、タイプに従って、作成されたエレメントに対してデータを変換することを含んでいる。インターフェイスは、その方法、プロパティ、および、イベントを含めて、投射され得る。投射は、また、例外（ｅｘｃｅｐｔｉｏｎ）をオペレーティングシステムからアプリケーションへプロパゲーションすることも含んでいる。

オペレーティングシステムのＡＰＩを他の言語の中にこうして投射することは、コンピューターで実行されるプロセス、一つまたはそれ以上のコンピューターストレージメディアを含む製造の手段、または、コンピューターマシンにおいて実施され得る。

以降の説明においては、添付の図面が参照される。図面は、明細書の一部を構成しており、説明図として、本技術に係る所定の実施例が示されている。本発明開示の範囲を逸脱することなく、他の実施例が使用され、構成の変更がなされ得ることが理解されるべきである。

図１は、ＡＰＩを他のプログラミング言語の中へ投射することを含むシステムのブロックダイヤグラムである。 図２は、開発ツールのオペレーション例を説明するフローチャートである。 図３は、コンパイラー又はインタープリターのオペレーション例を説明するフローチャートである。 図４は、こうしたシステムが実施されるコンピューターデバイスの実施例に係るブロックダイヤグラムである。

以下のセクションでは、こうしたネイティブシステムＡＰＩを他のプログラミング言語の中へ投射することが実施できるオペレーション環境の実施例が提供される。

図１を参照すると、実行されているアプリケーション１００は、実行時にオペレーティングシステム１０４のネイティブシステムＡＰＩ１０２にアクセスしている。アプリケーションがこうした機能性を有するように、プログラム１０６は、エディターといった、開発ツール１１２を典型的に使用して書かれている。こうしたプログラムは、言語のコンパイラー又はインタープリター１０８によってコンパイルまたはインタープリート（ｉｎｔｅｒｐｒｅｔ）のいずれかが行われて、実行時間アプリケーション（ｒｕｎｔｉｍｅ ａｐｐｌｉｃａｔｉｏｎ）１００を提供する。開発ツール１０２、および、コンパイラー又はインタープリター１０８は、オペレーティングシステムのＡＰＩ１０２を完全に記述するメタデータ１１０にアクセスする。開発ツール１０２は、開発者がプログラムを書くことを手助けする。メタデータを介して利用可能なネイティブシステムＡＰＩを開発者に通知し、こうしたＡＰＩが開発者のプログラミング言語を使用してアクセスできるようにしている。コンパイラー又はインタープリターは、ネイティブシステムＡＰＩの開発者のプログラミング言語の中への投射をメタデータを使用して実施する。特に、ＡＰＩにおける名前付きエレメントは、対象言語における名前付けされたエレメントに対してマップされ、こうしたエレメントの中の値は、対象言語とオペレーティングシステムによって使用されるフォーマット間で変換される。

こうしたシステムの構築は、メタデータを用いて記述されたＡＰＩを伴うオペレーティングシステムを構築することから始まる。メタデータは、プログラミング言語の独立した形式で、ＡＰＩ記述の名前付けされたエレメントのそれぞれを表している。このメタデータは、インターフェイスの完全な記述を提供する。結合されたシステムメタデータは、ＥＣＭＡ−３３５ＣＬＩフォーマットで、一連のメタデータファイルの中に保管され得る。しかしながら、本発明にとって所定のフォーマットは重要ではない。

このコンテクストを仮定して、こうしたシステムの実施例が、図２から図４に関して、より詳細に説明される。

図２において、開発ツールのオペレーションの実施例がこれから説明される。開発者は、コンピュータープログラムを書くときに、エディターといった、開発ツール形式を一般的に使用する。このエディターは種々のタスクを行うことができる。文法を確認したり、開発者が入力した文字列の完了を提示するといったことである。この環境において、オペレーティングシステムのアプリケーションプログラミングインターフェイスを記述しているメタデータは、種々の方法で使用され得る。開発ツールは、入力された文字列を受け取る２００。ＡＰＩにおいて識別子（「マウス」といったもの）または名前空間（オペレーティングシステム名といったもの）として使用されるキーワードといったものである。メタデータは検索され２０２、識別子又は名前空間の一部として受け取った入力を有しているエレメントを特定する。マッチング（ｍａｔｃｈｉｎｇ）エレメント一式に対する識別子は集められて２０４、開発ツールに戻される。開発ツールは、選択のために開発者に対してエレメントを提示し２０６、メタデータからの情報を使用して、開発者が使用しているコンピューター言語にとって好適なフォーマットでそうしたエレメントを提示する。

図３を参照して、これから言語コンパイラー又はインタープリターのオペレーションの実施例が説明される。コンピュータープログラムの処理において、コンパイル又はインタープリートであっても、コンピュータープログラムの一連のエレメントが検知される３００。コンピュータープログラムのエレメントがオペレーティングシステムのＡＰＩに関連するかどうかが判断される３０２。例えば、メタデータにおけるエレメントを検索することによって、このことが判断され得る。メタデータを使用して、投射エレメントが作成される３０４。投射データは、コンピュータープログラムとオペレーティングシステムとの間でデータを交換できるようにする。特に、コンパイラー又はインタープリターは、オペレーティングシステムのＡＰＩにおける名前付きエレメントを対象言語における名前付きエレメントに対する投射を実施する。メタデータにより、オブジェクトが作成され、プログラムによって使用されるデータフォーマットとオペレーティングシステムによって使用されるフォーマットとの間で値を変換することができる。実行時に、このエレメントにより、プログラムは、オペレーティングシステムのＡＰＩにアクセスすることができ３０６、アプリケーションとオペレーティングシステムとの間でデータを変換することができる。

こうしたシステムの一般的なオペレーションが説明されてきたので、これから所定の実施例が説明される。特に、ＡＰＩを記述するメタデータとＡＰＩのエレメントのコンピューター言語所定の表現との間の投射の実施例に係るさらなる詳細がこれから説明される。

以降の説明は、単なる一つの可能な実施例に関するものであり、本発明を限定するものと考えられるべきではない。特に、以降の記載は実施可能な言語投射の単なる実施例であり、この言語に対する他の実施が可能であり、他の言語への他の投射が可能であることが理解されるべきである。

この実施例においては、ＪａｖａＳｃｒｉｐｔが、メタデータを使用してネイティブシステムＡＰＩの中に投射されるプログラミング言語である。以下の実施例においては、いくつかの種類のエレメントが、どのようにＪａｖａＳｃｒｉｐｔプログラミング言語の中に投射されるかが説明される。

スクリプトが、オペレーティングシステムのＡＰＩによって規定された所定のオブジェクトのインスタンスを作成するように試みるとき、プロジェクター（Ｐｒｏｊｅｃｔｏｒ）オブジェクトがメタデータへのアクセスを担い、異なるタイプ間でのデータを変換するスタブ（ｓｔｕｂ）を作成する。おそらくプロキシーオブジェクトの作成を含んでおり、メソッド呼び出しをディスパッチ（ｄｉｓｐａｔｃｈ）するために、イベントを管理して、コールバックファンクションを管理している。

整数、文字列、等といった、基本タイプの名前付きエレメントに対して、以降の記載は、こうしたＡＰＩエレメントをＪａｖａＳｃｒｉｐｔの中に投射する方法である。

オペレーティングシステムは、いくつかの署名された整数タイプと署名のない整数タイプを有している。１バイトの署名のない整数（ＵＩｎｔ８）、４バイトの署名のない整数（ＵＩｎｔ３２）、１バイトの署名された整数（Ｉｎｔ８）、８バイトの署名された又は署名のない整数（Ｉｎｔ６４とＵＩｎｔ６４）といったものである。こうしたタイプの名前付けされたエレメントが、ＪａｖａＳｃｒｉｐｔナンバー値として投射される。ＪａｖａＳｃｒｉｐｔナンバーがオペレーティングシステム値へと変換される場合、その値はＪａｖａＳｃｒｉｐｔナンバーに型強制（ｔｙｐｅ ｃｏｅｒｃｅ）され、ＥＳ５ ＴｏＩｎｔ３２規格によって定義されたプロセスが続く。ＵＩｎｔ８に対して、結果はモジュロ（ｍｏｄｕｌｏ）２＾８が適用される。Ｉｎｔ３２に対しては、モジュロ２＾１６が適用される。ＵＩｎｔ３２に対しては、モジュロ２＾３２が適用される。

ＪａｖａＳｃｒｉｐｔ値へと変換された６４ビットの整数は、標準ナンバー値として表現される。署名された整数で範囲[−２＾５３、２＾５３]にある場合、または、署名のない整数で範囲[０、２＾５３]にある場合である。この範囲の外側にある場合は、整数データの全６４ビットを保持するカスタムバッキングストア（ｃｕｓｔｏｍ ｂａｃｋｉｎｇ ｓｔｏｒｅ）を用いてナンバー値として表される。こうしたカスタムナンバー値上での数学的オペレーションにより、その値を、範囲[−２＾５３、２＾５３]、または、署名のない場合[０、２＾５３]の範囲における標準ナンバー表現にされる。値がこの範囲の外側にある場合、タイプエラー（Ｔｙｐｅ Ｅｒｒｏｒ）が生じる。６４ビットの整数へと変換されたＪａｖａＳｃｒｉｐｔ値は、それが投射された値それ自身である場合は、直接的に割り当てられる。そうでなければ、その値にＥＣ５”ＴｏＩｎｔｅｇｅｒ”転換を適用した結果が渡される。

キャラクター（１６ビットのユニコードにより表されるもの）、文字列、または、グローバル一意識別子（ＧＵＩＤ）であるオペレーティングシステムのＡＰＩに係る名前付きエレメントは、ＪａｖａＳｃｒｉｐｔの文字列として表現することができ、ＪａｖａＳｃｒｉｐｔにおける名前付き文字列へと投射される。

ＪａｖａＳｃｒｉｐｔへと変換されたキャラクターは、ユニコード値によって表わされる単一キャラクターを含むＪａｖａＳｃｒｉｐｔ文字列値へと転換される。キャラクターへと変換されたＪａｖａＳｃｒｉｐｔ値は、ＥＳ５ ＴｏＳｔｒｉｎｇオペレーションを介してＪａｖａＳｃｒｉｐｔ文字列へと型強制され、最初のキャラクターは保持される。そして、単一のキャラクターはＣｈａｒ１６値として渡される。

ＪａｖａＳｃｒｉｐｔへと変換された文字列は、ＪａｖａＳｃｒｉｐｔストリング（Ｓｔｒｉｎｇ）に転換される。文字列へと変換されたＪａｖａＳｃｒｉｐｔ値は、ＪａｖａＳｃｒｉｐｔストリングへと型強制される。

ＪａｖａＳｃｒｉｐｔ値へと変換されたＧＵＩＤは、文字列フォーマットへと転換される。ＧＵＩＤへと変換されたＪａｖａＳｃｒｉｐｔ値は、文字列へと型強制され、そして、オペレーティングシステムによって使用されるフォーマットへと構文解析される。

オペレーティングシステムは、名前付きエレメントを伴うＡＰＩを有することができる。名前付きエレメントは、ある時点を表わすＤａｔｅＴｉｍｅストラクト（ｓｔｒｕｃｔ）、または、時間量を表すＴｉｍｅＳｐａｎストラクトである。ＤａｔｅＴｉｍｅストラクトは、ＤａｔｅＴｉｍｅストラクトデータ（Ｄａｔａインスタンスとは異なる範囲と精度を有するもの）と一致するバッキングストアを用いて、ＤａｔａインスタンスとしてＪａｖａＳｃｒｉｐｔの中に投射され得る。ＴｉｍｅＳｐａｎストラクトはミリ秒に転換され、ＪａｖａＳｃｒｉｐｔナンバーとしてリターンされる。同様に、ＪａｖａＳｃｒｉｐｔナンバーはミリ秒から１００ナノ秒単位に転換することができ、ＴｉｍｅＳｐａｎストラクトとして渡される。

メタデータのインタープリートにより、投射は、いくつかの場合において、タイプをネイティブ環境から言語投射における既存のタイプへと再度マップすることもできることに留意すべきである。例えば、このことは、ネイティブＡＰＩにおけるタイプと言語投射が互換性のあるデータレイアウトを有している場合に可能であり望ましいものであって、基本的なデータタイプについて容易に生じるものである。メタデータのマッピングを用いて、投射は、言語タイプ上のメソッド又はプロパティといった、全てのオペレーションを直接的にネイティブタイプへ単純にリダイレクト（ｒｅｄｉｒｅｃｔ）することができる。これにより、こうしたタイプの使用は、言語開発者にとって、より自然でよく知られたものになる。例えば、ＤａｔｅＴｉｍｅストラクトの再度マップは、こうしたやり方で実施される。ネイティブＡＰＩにおいて、ＤａｔｅＴｉｍｅストラクトは、あらゆる追加のオペレーションなしにメタデータにおいてＷｉｎｄｏｗｓ（登録商標）．Ｆｏｕｎｄａｔｉｏｎ．ＤａｔｅＴｉｍｅとして表される。Ｃ＃投射において、このタイプは、サポートが豊富なＣ＃におけるＳｙｓｔｅｍ．ＤａｔｅＴｉｍｅＯｆｆｓｅｔにリダイレクトされ得る。

別の実施例として、ＡＰＩにおける名前付きエレメントがメソッドである場合、そのエレメントはリターンタイプとしての値ＨＲＥＳＵＬＴを有し、ＪａｖａＳｃｒｉｐｔにおける例外に転換される。リターンされたＨＲＥＳＵＬＴは、ＪａｖａＳｃｒｉｐｔエンジンによって成功が確認される。ＨＲＥＳＵＬＴが失敗を示している場合、ＪａｖａＳｃｒｉｐｔエンジンは、ＪａｖａＳｃｒｉｐｔ側に例外を投げかける。従って、オペレーティングシステムのＡＰＩのメソッドを実施しているＪａｖａＳｃｒｉｐｔに対して、ＨＲＥＳＵＬＴの失敗がＪａｖａＳｃｒｉｐｔ Ｅｘｃｅｐｔｉｏｎとしてサーフェス（ｓｕｒｆａｃｅ）される。ＪａｖａＳｃｒｉｐｔメソッドを使用しているＡＰＩメソッド（以下に説明されるコールバック（ｃａｌｌ ｂａｃｋ）又はデリゲート（ｄｅｌｅｇａｔｅ）といったもの）に対して、ＪａｖａＳｃｒｉｐｔメソッドコールが例外ブロック（または、ＡＰＩをホストしているＪａｖａＳｃｒｉｐｔによって提供されるような等価なもの）の中にラップされる。捉えた例外がＨＲＥＳＵＬＴとしてプロパゲーションされ得るようにである。しかしながら、オペレーティングシステムは、また、ＨＲＥＳＵＬＴがメソッドとプロパティのパラメーター位置の中又は外にあるようにしている。こうした場合、ＨＲＥＳＵＬＴは署名のない３２ビットチップとして変換される（上述のようにである）。

列挙型（ｅｎｕｍｅｒａｔｅｄ ｔｙｐｅ）であるＡＰＩにおける名前付きエレメント、つまり名前付きコンスタント（ｃｏｎｓｔａｎｔ）一式、に対しては、それぞれの名前付き値に対する読み出し専用フィールドを含むオブジェクトとしてＪａｖａＳｃｒｉｐｔにおいて表現される。

「ストラクト（”ｓｔｒｕｃｔ”）」であるＡＰＩにおける名前付きエレメント、つまり名前付きフィールドの集合、に対しては、ＪａｖａＳｃｒｉｐｔオブジェクトとしてＪａｖａＳｃｒｉｐｔにおいて表現される。ＪａｖａＳｃｒｉｐｔへと変換されたストラクトはオブジェクトへと転換される。ストラクトにおけるそれぞれの名前付きフィールドの値は、フィールドの基礎的なタイプごとに変換される。オブジェクトタイプであるＪａｖａＳｃｒｉｐｔ値は、ストラクトへと変換され得る。ＪａｖａＳｃｒｉｐｔオブジェクト又はそのプロトタイプは、ストラクトのそれぞれの名前付きフィールドに対する名前付きフィールドを含んでおり、それぞれの名前付きフィールドの値は、基礎的なタイプに従って変換される。ＪａｖａＳｃｒｉｐｔオブジェクトにおける追加のフィールドで、オペレーティングシステムのＡＰＩストラクトにおける均等物を有さないものは、無視される。ストラクト値の変換が失敗した場合、変換エラーがリターンされる。

この実施例において、オペレーティングシステムは、アレイ（ａｒｒａｙ）に対するタイプを有していないが、代わりに、メソッドに対する引数が、アレイにおけるエレメントの数を表している署名のない整数長さ、バイトでなく、のペアとなるようにできる。アレイの最初のエレメントに対するポインターが後に続くものである。

アレイをＪａｖａＳｃｒｉｐｔへと変換する場合、以下の特性をもつオブジェクトが作成される。オブジェクトは、０とアレイの長さ、マイナス１、との間のそれぞれの整数値に対するプロパティを有しており、それらは加算（ｅｎｕｍｅｒａｂｌｅ）で、書き込み可能であるが、構成可能ではない。そして、「長さ（’ｌｅｎｇｔｈ’）」のプロパティは、初期的にベクトル長に設定されており、それは書き込み不可能であり、加算でなく、構成可能ではない。プロトタイプは、Ａｒｒａｙプロトタイプオブジェクトである。インデックスプロパティ上の[[Put]]オペレーションは、基本的なネイティブアレイ上に所定のインデックスを設定する。インデックスプロパティ上の[[GetOwnProperty]]オペレーションは、基本的なネイティブアレイへとインデックスする。Ａｒｒａｙとして[[Class]]は有していない。ＪａｖａＳｃｒｉｐｔオブジェクトを変換するとき、オブジェクトが[[Class]]Ａｒｒａｙを有するとすれば、アレイはネイティブアレイへとコピーされ、このアレイに対する参照が伝達される。オブジェクトが投射されたアレイであれば、基本的なネイティブアレイが伝達される。

ＡＰＩは、また、デリゲート（ｄｅｌｅｇａｔｅ）又はコールバックファンクションである名前付きエレメントを有することができ、一つの実施可能な方法に関するものである。これらは、コール可能なオブジェクトとしてＪａｖａＳｃｒｉｐｔの中へ投射され得る。投射は、カスタム変換オブジェクトにおけるコールバックデリゲートをラップする。

ＪａｖａＳｃｒｉｐｔへと変換されたデリゲートは、ＪａｖａＳｃｒｉｐｔファンクションオブジェクトの中にラップされる。ファンクションオブジェクトが実施された場合、引数は、デリゲートによって規定されるように均等なパラメーターへと変換され、ラップされたデリゲートオブジェクトが実施される。引数の変換が失敗した場合、デリゲートはフェイル（ｆａｉｌ）をコールする。パラメーターにおけるデリゲートよりも少ないＪａｖａＳｃｒｉｐｔ引数しかない場合、デリゲートはフェイルをコールする。パラメーターにおけるデリゲートを超える追加のＪａｖａＳｃｒｉｐｔ引数は無視される。デリゲートが実施された後で、アウトパラメーター（ｏｕｔ ｐａｒａｍｅｔｅｒ）はＪａｖａＳｃｒｉｐｔタイプへと変換される。アウトパラメーターの変換が失敗した場合、デリゲートはフェイルをコールする。そして、アウトパラメーターはＪａｖａＳｃｒｉｐｔ値に変換されて、リターンされる。

ネイティブＪａｖａＳｃｒｉｐｔファンクションオブジェクトがデリゲートへと変換される場合、コール可能なオブジェクトは、対応するデリゲートタイプのデリゲートの中にラップされる。デリゲートが実施されるとき、インパラメーター（ｉｎ ｐａｒａｍｅｔｅｒ）がＪａｖａＳｃｒｉｐｔタイプへと変換されて、ＪａｖａＳｃｒｉｐｔファンクションオブジェクトが実施される。引数の変換に失敗した場合、デリゲートコールはフェイルする。デリゲートが実施された後で、リターン値が、以下のルールに基づいてデリゲートのアウトパラメーターへとマップされる。第１に、アウトパラメーターが存在しない場合は、ＪａｖａＳｃｒｉｐｔファンクションオブジェクトからのリターン値は無視される。第２に、デリゲートが一つのアウトパラメーターを規定する場合は、ＪａｖａＳｃｒｉｐｔファンクションオブジェクトからのリターン値は、そのタイプへと変換される。その変換が失敗した場合、デリゲートコールはフェイルする。第３に、デリゲートが複数のアウトパラメーターを規定する場合は、ＪａｖａＳｃｒｉｐｔファンクションオブジェクトからのリターン値は、それぞれのアウトパラメーターに対する名前付きプロパティを伴うオブジェクトである。それぞれの名前付きプロパティは、対応するアウトパラメーターのタイプへと変換される。リターン値がオブジェクトでない場合、デリゲートコールはフェイルする。リターンされたオブジェクトがそれぞれのアウトパラメーターに対する名前付きプロパティを含まない場合、デリゲートコールはフェイルする。リターンされたオブジェクトが、アウトパラメーターに対応していない追加の名前付きプロパティを含む場合、それらは無視される。名前付きプロパティの対応するアウトパラメータータイプへの変換が失敗した場合、デリゲートコールはフェイルする。

以下の実施例は、ＩＳｔｒｉｎｇ Ｃｏｌｌｅｃｔｉｏｎと呼ばれるデリゲートのためのメタデータと、このデリゲートのインスタンスを作成する擬似ＪａｖａＳｃｒｉｐｔコードを説明するものである。

Example metadata:
[uuid(…)]
delegate HRESULT Comparer([in] HSTRING s1,[in] HSTRING s2,[out,retval] Boolean*value)
interface IStringCollection
{
HRESULT Sort([in] Comparer compare);
}

Psuedo-JavaScript:
//create an instance of a class that implements IStringCollection
strCol=getIStringCollection()
strCol.sort(function(s1,s2){returen s1>s2;});

インターフェイスは、オブジェクトとして直接的にＪａｖａＳｃｒｉｐｔへと投射されるものではない。しかしながら、インターフェイスは、オペレーティングシステムのＡＰＩメソッドのパラメーター及びリターンタイプであり得る。

上記の実施例で、対象プログラミング言語において自然な投射を提供するために、メンバーがＪａｖａＳｃｒｉｐｔへと投射され、ネームがｃａｍｅｌＣａｓｅに変更される。メンバーに対してｃａｍｅｌＣａｓｅネームを使用するためのＪａｖａＳｃｒｉｐｔにおける文字列変換に従ったものである。ＪａｖａＳｃｒｉｐｔコンストラクター（ｃｏｎｓｔｒｕｃｔｏｒ）ファンクションに類似のタイプは、慣習的にＰａｓｃａｌＣａｓｅであり、その形式に投射される。同様に、ｅｎｕｍ型プロパティ、ストラクトフィールド、ａｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒパターンのイベント名は、ｃａｍｅｌＣａｓｅにおけるネームを有している。

実行時間クラスの表現となる静的タイプ情報に基づいては知られていないインターフェイスインスタンスは、ＪａｖａＳｃｒｉｐｔへと変換されて、以下のステップを通過する。第１に、インターフェイスへのコールがなされてインターフェイスに対する実行時間クラス名が獲得される。成功の場合、オブジェクトは、実行時間クラスインスタンスオブジェクト（以下に説明される）として投射される。そうでなければ、オブジェクトは、それが実施するように知られているまさにそのインターフェイスを実施する名前付けされていない実行時間クラスのインスタンスであるかのように投射される。それは、他動的に（ｔｒａｎｓｉｔｉｖｅｌｙ））要求されるインターフェイスである。

インターフェイスタイプに変換されているＪａｖａＳｃｒｉｐｔ値が検査される。それが投射された実行時間クラスインスタンスオブジェクトであるか、または、投射されたインターフェイスインスタンスオブジェクトであるかが検査される。それが実行時間クラスオブジェクトであり、そのオブジェクトがプロキシーする（ｐｒｏｘｙ）オリジナルの値がインターフェイスタイプを実施する場合、インターフェイスのオブジェクト実施がオペレーティングシステムに渡される。そうでなければ、タイプエラー例外が生じる。

オペレーティングシステムのＡＰＩにおけるオブジェクトは、実行時間クラスのインスタンスであってよい。実行時間クラスは、一式の一つまたはそれ以上のインターフェイス（以下に定義されるもの）を実施する。実行中のオブジェクトに係る実施されたインターフェイスのリストは、実行中のオブジェクトをリターンしたメソッドのメタデータに基づくか、または、実行時間クラス名にアクセスしてメタデータを検索することによるか、いずれかにより決定され得る。ＪａｖａＳｃｒｉｐｔは、プロトタイプベースの動的言語であるため、クラスの構造を有さない。クラス構造は、オブジェクトとしてＪａｖａＳｃｒｉｐｔに投射される。

このように、オペレーティングシステムのＡＰＩオブジェクトは、オブジェクトとしてＪａｖａＳｃｒｉｐｔに投射される。クラスの全ての実施されたインターフェイス上で定義されるメソッド、プロパティ、および、イベントの結合は、タイプメンバーを表しており、投射されたＪａｖａＳｃｒｉｐｔオブジェクト上で利用可能な名前付きプロパティとして、プロトタイプを介して、示される。ＪａｖａＳｃｒｉｐｔ言語投射の使用者は、どのインターフェイス上にメンバーが実際に定義されているかを気にすることなく、クラスのあらゆるメンバーに直接的にアクセスすることができる。

ＪａｖａＳｃｒｉｐｔオブジェクトは動的である。新たなプロパティがいつでも追加され、または、削除され得ることを意味している。投射されたオブジェクトは、新たなプロパティとメソッドの追加をサポートすることができる。既定のインターフェイスメンバーがオーバーライド（ｏｖｅｒｒｉｄｅ）または削除されない限りにおいてである。ＪａｖａＳｃｒｉｐｔ表現において、投射されたオブジェクトは拡張可能であるが、名前付きタイプメンバーの集合は構成可能ではない。投射されたオブジェクトは、実行時間クラス実施のインターフェイスからのメンバーの集合上で定義されたインスタンスメンバーを伴うプロトタイプを有している。

そうしたインターフェイスは、上述のように、メソッド、パラメーター、および、イベントを有している。

言語投射レイヤー（ｌａｙｅｒ）でのメソッドは、メソッドごとのスロットを用いて仮想関数テーブル（ｖｔａｂｌｅ）として実施される。インターフェイスに関するメタデータは、メソッドと同様に、パラメーターのネーム（ｎａｍｅ）、タイプ、および、ダイレクション（イン／アウト）を提供する。メソッドは、投射された実行時間クラス上のコール可能なプロパティ、または、インターフェイスオブジェクトとしてＪａｖａＳｃｒｉｐｔに投射される。こうしたプロパティは、以下のとおりである。｛Writable=false, Enumerable=true, Configurable=false｝ コールされた場合、引数は対応するパラメータータイプに従って変換され、メソッドは、これらの値を用いてコールされる。リターン値は、ＪａｖａＳｃｒｉｐｔ値に変換され、値としてのＪａｖａＳｃｒｉｐｔオブジェクトを伴うものである。

言語投射レイヤーでのプロパティは、ゲット（ｇｅｔ）及び/又はセット（ｓｅｔ）メソッドとして実施される。プロパティ値のアクセスがゲットメソッドをコールし、一方でプロパティ値の更新はセットメソッドを実施する。プロパティは、読み出し又は書き込み（つまり、ゲット及びセットメソッドが利用可能である）であってよく、または、読み出し専用であってよい（つまり、ゲットメソッドだけが利用可能である）。プロパティは、ＪａｖａＳｃｒｉｐｔの中にプロパティとして投射される。プロパティ値の変換は、上述のように、基本的なプロパティタイプに基づいて作用する。

言語投射レイヤーでのイベントは、アッド（ａｄｄ）及び/又はリムーブ（ｒｅｍｏｖｅ）メソッドとして実施される。アッドメソッドは、デリゲートインスタンスを得てリスナー（ｌｉｓｔｅｎｅｒ）を記述するデータをリターンする。一方で、リム−ブメソッドは、リスナーを記述するデータ得て何もリターンしない。

ＪａｖａＳｃｒｉｐｔにおいて、少なくとも一つのイベントが投射されているあらゆる投射された実行時間クラス又はインターフェイスオブジェクトは、そのプロパティに２つのプロパティが追加される。ａｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒとｒｅｍｏｖｅＥｖｅｎｔＬｉｓｔｅｎｅｒである。これらのプロパティは、{Writable:false,Enumerable:true,Configurable:fales}であり、コール可能なオブジェクトとなるように割り当てられる。

ａｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒファンクションは、リスン（ｌｉｓｔｅｎ）するイベントの名前を表す文字列引数、リスナーとして割り当てるためにコールバックファンクション、および、無視されている任意の第３のパラメーターを獲得する。このファンクションは、基本的なａｄｄ＿Ｅｖｅｎｔメソッドをコールし、変換されたコールバックファンクションをデリゲートとして渡して、結果として生じたトークン（ｔｏｋｅｎ）をコールバックファンクションオブジェクトの参照識別子によってキー付けされたマップの中に保管する。

ｒｅｍｏｖｅＥｖｅｎｔＬｉｓｔｅｎｅｒは、リスナーから取り除くイベントの名前を表す文字列引数、取り除かれるべきコールバックファンクション、および、無視されている任意の第３のパラメーターを獲得する。このファンクションは、保管されたトークンのマップにおける参照識別子によってコールバックファンクションを検索して、トークンが見つかった場合に、基本的なｒｅｍｏｖｅ＿Ｅｖｅｎｔメソッドをコールし、検索されたトークンを渡す。

イベントが開始されると、コールバックとして渡されたあらゆるＪａｖａＳｃｒｉｐｔファンクションオブジェクトが実施される。ファンクションオブジェクトに渡された引数は、ＥｖｅｎｔＨａｎｄｌｅｒデリゲートに提供される引数の変換された値になる。

上述のように、言語に対するＡＰＩ投射レイヤーを有することにより、オペレーティングシステムのＡＰＩに係る名前付きエレメントは、オペレーティングシステムの中に保管されたメタデータによって規定されるように、オペレーティングシステムのＡＰＩフォーマットとアプリケーションプログラミング言語フォーマットとの間のオブジェクト及び変換データを自動的に作成するために使用される。上記は、例示オペレーティングシステムと例示プログラム言語との間の単なる例示投射であること、および、本発明がこの実施例に限定されるものではないことが理解されるべきである。

実施例について説明してきたので、そうしたシステムが動作するようにデザインされたコンピューター環境についてこれから説明する。以降の記載は、このシステムが実施され得る好適なコンピューター環境について簡潔で一般的な説明を提供するように意図されたものである。システムは、数多くの汎用又は専用コンピューターハードウェア構成を用いて実施することができる。好適なよく知られたコンピューターデバイスの実施例は、これらに限定されるわけではないが、以下のものを含んでいる。パーソナルコンピューター、サーバーコンピューター、ハンドヘルド又はラップトップデバイス（例えば、メディアプレーヤー、ノートブックコンピューター、携帯電話、パーソナルデータアシスタント、ボイスレコーダー）、マルチプロセッサシステム、マイクロプロセッサベースシステム、セットトップボックス、ゲームコンソール、プログラム可能な家電、ノートブックＰＣ、ミニコンピューター、メインフレームコンピューター、上記のあらゆるシステム又はデバイスを含む分散コンピューティング環境、等である。

図４は、好適なコンピューターシステム環境の実施例を示している。コンピューターシステム環境は、好適なコンピューター環境の単なる一例であって、こうしたコンピューター環境の範囲又は機能性に関していかなる限定も意図するものではない。コンピューター環境は、オペレーション環境の中に示されたあらゆる一つのコンポーネント又はその組み合わせに関していかなる依存も要求も有しないものとして理解されるべきである。

図４に関して、コンピューター環境の実施例は、コンピューターマシン４００といった、コンピューターマシンを含んでいる。最も基本的な構成において、コンピューターマシン４００は、典型的に、少なくとも一つのプロセッサユニット４０２とメモリー４０４を含んでいる。コンピューターデバイスは、複数のプロセッサユニット、及び/又は、グラフィックプロセッサユニット４２０といった追加のコプロセッサユニット（ｃｏ−ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）を含んでよい。コンピューターデバイスのまさにその構成とタイプに基づいて、メモリー４０は、揮発性（ＲＡＭといったもの）、不揮発性（ＲＯＭ、フラッシュメモリー、等といったもの）、または、これら２つのいくつかの組み合わせであってよい。この最も基本的な構成は、破線４０６によって図４の中に示されている。加えて、コンピューターマシン４００は、また、追加の特性／機能性を有し得る。例えば、コンピューターマシン４００は、また、追加ストレージ（リムーバブル及び/又は非リムーバブルのもの）を含んでよい。これらに限定されるわけではないが、磁気又は光ディスク又はテープを含んでいる。こうした追加ストレージは、リムーバブルストレージ４０８及び非リムーバブルストレージ４１０として図４の中に示されている。コンピューターストレージメディアは、揮発性と不揮発性、リムーバブルと非リムーバブルメディアを含んでおり、コンピュータープログラムインストラクション、データ構造、プログラムモジュール、または、他のデータといった情報を保管するためのあらゆる方法又は技術において実施される。メモリー４０４、リムーバブルストレージ４０８及び非リムーバブルストレージ４１０は、全てコンピューターストレージメディアの実施例である。コンピューターストレージメディアは、これらに限定されるわけではないが、以下のものを含んでいる。ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリーまたは他のメモリー技術、ＣＤ−ＲＯＭ、デジタル多目的ディスク（ＤＶＤ）または他の光ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気ストレージデバイス、または、所望の情報を保管するために使用でき、コンピューターマシン４００によってアクセスされ得る他のあらゆるメディア、である。

コンピューターマシン４００は、また、コミュニケーション接続４１２を含んでおり、デバイスは他のデバイスとコミュニケーションすることができる。コミュニケーション接続４１２は、コミュニケーションメディアの実施例である。コミュニケーションメディアは、典型的に、コンピュータープログラムインストラクション、データ構造、プログラムモジュール、または、キャリア波又は他の伝送メカニズムといった変調されたデータ信号における他のデータを保持しており、あらゆる情報伝達メディアを含んでいる。用語「変調されたデータ信号（”ｍｏｄｕｌａｔｅｄ ｄａｔａ ｓｉｇｎａｌ”）」は、一つまたはそれ以上の特性セットを有する信号、または、信号におけるエンコード情報に関して、そうしたやり方で変換された信号を意味しており、それによって、信号の受信装置の構成または状態が変化している。実施例として、そして限定ではなく、コミュニケーションメディアは、有線ネットワーク又はダイレクト有線接続、および、音声、ＲＦ、赤外線、又は他の無線メディアといった無線メディアを含んでいる。

コンピューターマシン４００は、ディスプレイ、キーボード、マウス、ペン、カメラ、タッチ入力デバイス、等といった種々の入力デバイス４１４を有してよい。スピーカー、プリンター、等といった出力デバイス４１６も、また、含まれてよい。こうしたデバイスの全ては従来技術としてよく知られており、ここにおいて長らく説明することを要しないものである。

こうしたシステムは、ソフトウェアの一般的なコンテクスト（ｃｏｎｔｅｘｔ）において実施され得る。プログラムモジュールといった、コンピューターで実行可能なインストラクション及び／又はコンピューターで解釈されるインストラクションを含み、コンピューターマシンによって処理されるものである。一般的に、プログラムモジュールは、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造、等を含み、プロセッサユニットによって処理されると、プロセッサユニットに対して所定のタスク又は所定の抽象的なデータタイプを実行するように指示する。このシステムは、分散コンピューター環境において実施されてもよい。タスクは、コミュニケーションネットワークを通じてリンクされた離れたプロセッサデバイスによって実行される。分散コンピューター環境において、プログラムモジュールは、メモリストレージデバイスを含むローカル及びリモート両方のコンピューターストレージメディアの中に存在し得る。

添付の請求項のプリアンブルにおける用語「製造方法」、「プロセス」、「マシン」、および、「組み合せ」は、米国特許法第１０１条におけるこれらの用語の使用によって定義される特許可能な技術的事項の範囲内にあるものと考えられる技術的事項に請求項を限定するように意図されたものである。

ここにおいて説明されたあらゆる又は全ての前出の代替的な実施例は、追加のハイブリッドな実施例を形成するために望まれるあらゆる組み合せにおいて使用され得るものである。添付の請求項において定められる技術的事項は、上述の所定の実施例に必ずしも限定されるものではないことが理解されるべきである。上述の所定の実施例は、単なる例として開示されたものである。

Claims (10)

1. コンピューターで実施される方法であって：
   オペレーティングシステムのアプリケーションプログラミングインターフェイスを記述するメモリーの中にメタデータを受け取るステップと；
   前記アプリケーションプログラミングインターフェイスのうち一つのエレメントに関するプログラミング言語におけるプログラムの中の名前付きエレメントの指標を受け取るステップと；
   前記メタデータを使用して、前記アプリケーションプログラミングインターフェイスの前記名前付きエレメントを投射するステップと、を含む、
   ことを特徴とする方法。
2. 前記投射するステップは、前記プログラムがコンパイルされるときに、
   一つまたはそれ以上のエレメントを作成するコードを作成するステップ、および、作成された前記エレメントをタイプに従って変換するステップと、
   を含む請求項１に記載の方法。
3. 前記投射するステップは、前記プログラムがインタープリートされるときに、
   一つまたはそれ以上のエレメントを作成するコードを作成するステップと、
   作成された前記エレメントをタイプに従って変換するステップと、
   を含む請求項１に記載の方法。
4. 前記投射するステップは、
   オペレーティングシステム表現とアプリケーション表現との間でタイプに従ってデータを変換するステップ、
   を含む請求項１に記載の方法。
5. 前記投射するステップは、
   メソッド、プロパティ、および、イベントを含むインターフェイスを投射するステップ、
   を含む請求項１に記載の方法。
6. 一つまたはそれ以上のプロセッサと；
   一つまたはそれ以上のコンピューターストレージメディアと；
   前記コンピューターストレージメディア上に保管されたコンピュータープログラムであり、プロセッサデバイスによって処理されるときに、オペレーティングシステムのアプリケーションプログラミングインターフェイスとプログラミング言語におけるアプリケーションとの間で言語投射を実施するコンピュータープログラムと、
   を含み、
   前記アプリケーションプログラミングインターフェイスは、メモリーの中に保管されたメタデータによって記述されており；
   前記言語投射は、
   前記アプリケーションプログラミングインターフェイスのうち一つのエレメントに関するプログラミング言語における名前付きエレメントの指標を受け取り、かつ、
   前記メタデータを使用して、前記アプリケーションプログラミングインターフェイスの前記名前付きエレメントを前記プログラミング言語における前記アプリケーションへ投射する、
   ことを特徴とするコンピューターマシン。
7. 前記投射は、前記プログラムがコンパイルされるときに、
   一つまたはそれ以上のエレメントを作成するコードを作成し、かつ、作成された前記エレメントをタイプに従って変換する、
   請求項６に記載のコンピューターマシン。
8. 前記投射は、前記プログラムがインタープリートされるときに、
   一つまたはそれ以上のエレメントを作成するコードを作成し、かつ、作成された前記エレメントをタイプに従って変換する、
   請求項６に記載のコンピューターマシン。
9. 前記投射は、
   オペレーティングシステム表現とアプリケーション表現との間でタイプに従ってデータを変換する、
   請求項６に記載のコンピューターマシン。
10. 前記投射は、
    メソッド、プロパティ、および、イベントを含むインターフェイスを投射する、
    請求項６に記載のコンピューターマシン。

Images