JP6255420B2 - 不変オブジェクトタイプ - Google Patents

Description

コンピューティングシステムは、ソフトウェアプログラムを実行することによって高度な機能を得る。プログラムは、ハードドライブ、コンパクトディスク、サムドライブ、フラッシュメモリなどの何らかの永続的な形で維持されるコンピュータ実行可能命令からなる。実行中、こうしたコンピュータ実行可能命令は、しばしばランダムアクセスメモリ内にロードされ、コンピューティングシステムの１つまたは複数のプロセッサによって実行されて、コンピューティングシステムにタスクを実行させることができる。

オブジェクト指向プログラミングでは、これらのコンピュータ実行可能命令は、機能呼び出しを介して対話し、１つまたは複数のプロパティを有し得るオブジェクトに編成される。管理コードは、タイプセーフを提供する管理環境内で実行するが、メモリ管理および例外処理も提供することができる。管理コードでは、オブジェクトは無限の寿命を有し、記憶に制限はなく、アクセス制限の方法は間接的であるかまたは追加のリソースを伴う。

システムレベルプログラミングは、システム全体を通じて、（オブジェクト）などのリソースへのアクセスおよびその寿命を厳しく効率的に管理することに基づいている。この厳しい管理を提供する１つの一般的な方法は、アプリケーションプログラムインターフェース（ＡＰＩ）を使用して、リソースの寿命およびアクセスを管理することである。

本明細書で説明する少なくともいくつかの実施形態は、システムプログラミングにおける安全性を向上させる言語拡張に関する。言語拡張に従い、タイプ全体が、そのタイプのすべてのインスタンスが不変である場合に、不変であるものと宣言され得る。不変タイプ宣言により、そのタイプのいずれのインスタンスも不変であるものとして自動的に扱われ、インスタンスのすべての直接または間接的に到達可能なメンバ（たとえばフィールド、メソッド、プロパティ）も、不変であるものとして自動的に扱われることになる。さらに、インスタンスのフィールド割り当てを可能にするいずれの構築時間基準も、作成者（creator）がインスタンスにアクセスできるようになる時点を超えて存続し続けることはできない。したがって、このインスタンス、およびその同じタイプの任意の他のインスタンスは、構築時点から不変となる。

こうしたすべてのインスタンスを不変として分類できることは、通常はリソースアクセスの安全性により許可されないはずのアクションが、不変な特徴によって許可されるため、有益である。たとえば、複数の構成要素および複数のスレッドがインスタンス上の相反するアクションを何らかの形で実行してもリスクがないため、それらの構成要素およびスレッド間でインスタンスを共有することができる。

本概要は、請求する主題の主要な特徴または必須の特徴を識別することを意図しておらず、請求する主題の範囲を決定する際の一助として用いることを意図している。

前述および他の利点および特徴が得られる方法を説明するために、様々な実施形態について、添付の図面を参照しながらより具体的に説明する。これらの図面は単なる例示的な実施形態を示しているため、本発明の範囲を限定するものとはみなされないことを理解し、添付の図面を用いることで、追加の具体性および細部と共に実施形態を記述および説明する。

本明細書で説明するいくつかの実施形態が採用可能なコンピューティングシステムを、抽象的に示す図である。 本明細書で説明する実施形態が採用可能な例示の環境を表す管理コードシステムを、抽象的に示す図である。 本明細書で説明する原理に従った、不変タイプ宣言が実行可能なソースコードのオーサリング環境を含む環境を示す図である。 本明細書で説明する実施形態に従った、オブジェクトタイプの複数のインスタンスが不変であることを保証するための方法の、フローチャートを示す図である。

本明細書で説明する実施形態によれば、タイプ全体を不変として宣言することができる、システムプログラミングにおける安全性を向上させる言語拡張について説明される。不変タイプ宣言により、そのタイプのいずれのインスタンスも不変であるものとして自動的に扱われ、インスタンスのすべての直接または間接的に到達可能なメンバ（たとえばフィールド、メソッド、プロパティ）も、不変であるものとして自動的に扱われることになる。さらに、インスタンスのフィールド割り当てを可能にするいずれの構築時間基準も、作成者がインスタンスにアクセスできるようになる時点を超えて存続し続けることはできない。したがって、このインスタンス、およびその同じタイプの任意の他のインスタンスは、構築時点から不変となる。こうしたすべてのインスタンスを不変として分類できることは、通常はリソースアクセスの安全性により許可されないアクションが、不変な特徴によって許可されるため、有益である。たとえば、複数の構成要素および複数のスレッドがインスタンス上の相反するアクションを何らかの形で実行してもリスクがないため、それらの構成要素およびスレッド間でインスタンスを共有することができる。

図１に関して、コンピューティングシステムのいくつかの導入的考察について説明する。次に図２に関して、管理コードシステムの原理について説明する。最後に図３および４に関して、不変タイプを宣言するための言語拡張の原理について説明する。

現在、コンピューティングシステムは、益々多様な形を取るようになってきている。たとえばコンピューティングシステムは、ハンドヘルドデバイス、電化製品、ラップトップコンピュータ、デスクトップコンピュータ、メインフレーム、分散型コンピューティングシステム、あるいは、従来はコンピューティングシステムとみなされなかったデバイスとすることができる。本説明および特許請求の範囲において、「コンピューティングシステム」という用語は、広義には、少なくとも１つの物理的かつ有形のプロセッサ、および、プロセッサによる実行が可能なコンピュータ実行可能命令を有することが可能な物理的かつ有形のメモリを含む、任意のデバイスまたはシステム（あるいはそれらの組み合わせ）を含むこととして定義される。メモリは、任意の形を取ることが可能であり、コンピューティングシステムの性質および形に依存することが可能である。コンピューティングシステムは、ネットワーク環境を介して分散可能であり、複数の構成コンピューティングシステムを含むことが可能である。

図１に示されるように、そのほとんどの基本構成において、コンピューティングシステム１００は、典型的には少なくとも１つの処理ユニット１０２およびメモリ１０４を含む。メモリ１０４は、揮発性、不揮発性、またはその２つの何らかの組み合わせとすることができる、物理システムメモリとすることができる。「メモリ」という用語は、本明細書では、物理記憶媒体などの不揮発性大容量ストレージを指すために使用することもできる。コンピューティングシステムが分散される場合、処理、メモリ、および／または記憶の機能も、同様に分散させることができる。本明細書で使用される場合、「実行可能モジュール」または「実行可能構成要素」という用語は、コンピューティングシステム上で実行可能なソフトウェアオブジェクト、ルーティング、または方法を指すことができる。本明細書で説明する異なる構成要素、モジュール、エンジン、およびサービスは、コンピューティングシステム上で（たとえば別々のスレッドとして）実行する、オブジェクトまたはプロセスとして実装することができる。

以下の説明では、１つまたは複数のコンピューティングシステムによって実行される動作を参照しながら、実施形態について説明する。こうした動作がソフトウェア内に実装される場合、動作を実行する関連付けられたコンピューティングシステムの１つまたは複数のプロセッサは、コンピュータ実行可能命令を実行させることに応答して、コンピューティングシステムの操作を指示する。たとえば、こうしたコンピュータ実行可能命令は、コンピュータプログラム製品を形成する１つまたは複数のコンピュータ可読媒体上に具体化され得る。こうした操作の例には、データの操作が含まれる。コンピュータ実行可能命令（および操作されたデータ）は、コンピューティングシステム１００のメモリ１０４に記憶することができる。コンピューティングシステム１００は、たとえばネットワーク１１０を介してコンピューティングシステム１００に他のメッセージプロセッサと通信させることが可能な通信チャネル１０８を含むこともできる。

本明細書で説明する実施形態は、以下でより詳細に考察するように、たとえば１つまたは複数のプロセッサおよびシステムメモリなどのコンピュータハードウェアを含む、特定用途向けまたは汎用のコンピュータを備えるかまたは使用することができる。本明細書で説明する実施形態は、コンピュータ実行可能命令および／またはデータ構造を搬送または記憶するための、物理的およびその他のコンピュータ可読媒体も含む。こうしたコンピュータ可読媒体は、汎用または特定用途向けのコンピュータシステムがアクセス可能な、任意の使用可能媒体とすることができる。コンピュータ実行可能命令を記憶するコンピュータ可読媒体は、物理記憶媒体である。コンピュータ実行可能命令を搬送するコンピュータ可読媒体は、伝送媒体である。したがって、限定ではなく例として、本発明の実施形態は、コンピュータ記憶媒体および伝送媒体という、少なくとも２つの明確に異なる種類のコンピュータ可読媒体を含むことができる。

コンピュータ記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたは他の光ディスクストレージ、磁気ディスクストレージまたは他の磁気記憶デバイス、あるいは、コンピュータ実行可能命令またはデータ構造の形の望ましいプログラムコード手段を記憶するために使用可能であり、汎用または特定用途向けのコンピュータによるアクセスが可能な、任意の他の媒体を含む。

「ネットワーク」は、コンピュータシステムおよび／またはモジュールおよび／または他の電子デバイスの間での電子データの移送を可能にする、１つまたは複数のデータリンクとして定義される。情報がネットワークまたは他の通信接続（ハードワイヤード、ワイヤレス、あるいはハードワイヤードまたはワイヤレスの組み合わせのいずれか）を介してあるコンピュータに転送または提供される場合、コンピュータは接続を伝送媒体として正しくみなす。伝送媒体は、コンピュータ実行可能命令またはデータ構造の形の望ましいプログラムコード手段を搬送するために使用可能であり、汎用または特定用途向けのコンピュータによるアクセスが可能な、ネットワークおよび／またはデータリンクを含むことができる。上記の組み合わせも、コンピュータ可読媒体の範囲に含まれるものとする。

さらに、様々なコンピュータシステム構成要素に到達すると、コンピュータ実行可能命令またはデータ構造の形のプログラムコード手段は、伝送媒体からコンピュータ記憶媒体に（またはその逆に）自動的に転送することができる。たとえば、ネットワークまたはデータリンクを介して受信されるコンピュータ実行可能命令またはデータ構造は、ネットワークインターフェースモジュール（たとえば「ＮＩＣ」）内のＲＡＭにバッファリング可能であり、その後最終的に、コンピュータシステムＲＡＭおよび／またはコンピュータシステムの揮発性の低いコンピュータ記憶媒体に転送可能である。したがって、コンピュータ記憶媒体は、伝送媒体も（あるいはこれを主に）使用するコンピュータシステム構成要素内に含めることができることを理解されたい。

コンピュータ実行可能命令は、たとえば、プロセッサで実行された場合、汎用コンピュータ、特定用途向けコンピュータ、または特定用途向け処理デバイスに、ある機能または機能グループを実行させる、命令およびデータを含む。コンピュータ実行可能命令は、たとえば２進数、アセンブリ言語などの中間形式命令、あるいはソースコードとすることができる。これまで、構造的な特徴および／または方法論的な動作に特有の言い回しで主題について説明してきたが、添付の特許請求の範囲で定義される主題は、必ずしも上記で説明した特徴または動作に限定されるものではないことを理解されよう。むしろ、説明した特徴および動作は、特許請求の範囲を実装する例示的な形として開示されている。

当業者であれば、本発明が、パーソナルコンピュータ、デスクトップコンピュータ、ラップトップコンピュータ、メッセージプロセッサ、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラム可能な家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、携帯電話、ＰＤＡ、ページャ、ルータ、スイッチなどを含む、多くのタイプのコンピュータシステム構成を備えるネットワークコンピューティング環境で実施可能であることを理解されよう。本発明は、ネットワークを介して（ハードワイヤードデータリンク、ワイヤレスデータリンク、またはハードワイヤードおよびワイヤレスのデータリンクの組み合わせによって）リンクされているローカルおよびリモートのコンピュータシステムがどちらもタスクを実行する、分散システム環境でも実施可能である。分散システム環境では、プログラムモジュールをローカルおよびリモートの両方のメモリ記憶デバイス内に配置することができる。

図２は、本明細書で説明する原理が動作可能な環境２００を示す。環境２００は、オブジェクトグラフの隔離および変更可能性を追跡するフレームワーク２１０を含む。フレームワーク２１０は、リファレンスへのアクセスを制御することによって、オブジェクトグラフに対する様々なリファレンス２２１を編成する。リファレンスは、ローカル変数、メソッドパラメータ、オブジェクトフィールド、またはオブジェクトグラフへの任意の他のリファレンスとすることができる。図示された実施形態では、リファレンス２２１はリファレンス２２１Ａから２２１Ｅを含むものとして示されているが、省略記号２２１Ｆは、フレームワーク２１０が任意数のリファレンス２２０へのアクセスを管理できることを象徴的に表している。

フレームワーク２１０は、リファレンスに許可を割り当てることによって、リファレンス２２１へのアクセスを管理する。「許可」は、リファレンスを変更することができるかどうかに関する何らかのプロパティを示す、リファレンス上の注釈である。こうした許可は、図２では許可２１１によって抽象的に表されている。許可は、読み取り可能許可２１１Ａ、書き込み可能許可２１１Ｂ、および不変（イミュータブル）許可２１１Ｃを含む。

「読み取り可能」許可２１１Ａは、対応するオブジェクト（ならびに、その直接および間接的に到達可能なメンバのすべて）が、読み取りのみ可能であることを意味する。

「書き込み可能」許可２１１Ｂは、対応するオブジェクトが書き込み可能であることを意味する。

「不変」許可２１１Ｃは、読み取り可能許可２１１Ａと同様であるが、このオブジェクトに対して書き込み可能なリファレンスを有する者がいないことをさらに保証する。不変許可２１１Ｃは、このオブジェクトに対する書き込み可能リファレンスが二度と存在しないことをさらに保証できる。したがって、不変許可２１１Ｃは、対応するオブジェクトが今後一切書き込まれないこと（ならびに、その直接および間接的に到達可能なメンバのすべてが今後一切書き込まれないこと）、ならびに、そのフィールドのすべて、およびそのフィールドのフィールドのすべて、なども同様に、今後一切書き込まれないことを意味する。オブジェクト内のすべての静的フィールドは、フレームワーク２１０によって不変許可２１１Ｃを有するとして扱われる。

「フレッシュ」許可２１１Ｄは、１）戻されたリファレンスによって参照される特定のオブジェクトグラフ（または特定のオブジェクトグラフ内の任意のオブジェクト）に対する外部リファレンスが存在しないこと、および、２）オブジェクトグラフ外部のいずれのオブジェクトに対しても、オブジェクトグラフ内に変更可能リファレンスが存在しないこと、を表す。「未構築」許可２１１Ｅについては、以下でより詳細に説明する。

フレームワーク２１０は、メモリ位置を隔離されているものとして注釈付けする、隔離メモリマネージャ２１２も含む。記憶位置に関する「隔離」注釈は、その位置が、外部的に一意な値を記憶することを意味する。すなわち、その位置に記憶されるいずれのオブジェクトについても、システム内にその位置に対する外部リファレンスは存在せず、その位置に記憶されるオブジェクトの直接または間接的に到達可能ないずれのメンバに対するいずれのリファレンスも存在しない。たとえば、隔離メモリマネージャ２１２は、隔離メモリ位置２２２を管理する。隔離メモリ位置は、２つの隔離メモリ位置２２２Ａおよび２２２Ｂを含むものとして示されているが、省略記号２２２Ｃは、隔離メモリ位置２２２が任意数の隔離メモリ位置を含み得ることを表す。

注釈構成要素２０１は、フレームワーク２１０上に構築される。代替としてまたは加えて、注釈構成要素２０１はフレームワーク２１０の一部として動作し得る。注釈構成要素２０１は、図２のリファレンス２２１のうちの１つなどのリファレンスを戻す実行可能構成要素を評価するように構成される。

本説明は、いったん構築が完了すると常に不変であるタイプをどのように表すかに関するリファレンス許可に対処する、システムにおける課題を対象とする。これらのタイプのフィールドは不変かつ読み取り専用であり、書き込み可能リファレンスを介しても変更は不可能である。変更の発生が可能なメカニズムが単に存在しない。以下、これらのタイプを「不変タイプ」と呼び、それ以外はすべて「変更可能タイプ」と呼ぶ。

不変タイプは、異なる構成要素および異なるスレッド間で自由に共有可能なデータ片を表すため、システムプログラミングにおいて共通である。１つの構成要素が、別の構成要素に対してその影響が目に見えるような方法でデータを変更し得るほど危険なことはない。

不変タイプの分類における第１の課題は、不変タイプがしばしば、それらのコンストラクタに対して「書き込み可能」として分類される入力パラメータを取ることである。しかしながら、書き込み可能入力はフィールドに、また構築中のインスタンスにも記憶されず、したがって、オブジェクトタイプは全体としてもはや不変とはみなされず、その代わりに変更可能となる。しかしながら、不変タイプは、書き込み可能入力パラメータに基づいて何らかの不変データを計算した後、その最終的な不変値をフィールドとして記憶することができる。したがって不変タイプは、対応するインスタンスが構築された時点から、その不変な特徴を保持する。

コンストラクタへの入力が不変またはフレッシュな入力のみを含む場合、オブジェクトは「不変」に昇格することができる。しかしながら、この規則によって、結果的にすべての不変オブジェクトが不変として分類されることにはならない。たとえば、以下の疑似コード例について考えてみる。
ｐｕｂｌｉｃ ｃｌａｓｓ Ｃｏｎｔａｉｎｅｒ
｛
ｒｅａｄｏｎｌｙ ｉｍｍｕｔａｂｌｅ ｓｔｒｉｎｇ ｍ＿ｎａｍｅ；
ｒｅａｄｏｎｌｙ ｉｍｍｕｔａｂｌｅ ｓｔｒｉｎｇ ｍ＿ａｄｄｒｅｓｓ；
ｐｕｂｌｉｃ Ｃｏｎｔａｉｎｅｒ（ｗｒｉｔａｂｌｅ Ｓｔｕｄｅｎｔ ｓｔｕｄｅｎｔ）
｛
ｍ＿ｎａｍｅ＝ｓｔｕｄｅｎｔ．Ｎａｍｅ；
ｍ＿ａｄｄｒｅｓｓ＝ｓｔｕｄｅｎｔ．Ａｄｄｒｅｓｓ；
｝
｝

この例で、Ｃｏｎｔａｉｎｅｒは実際には構築後は不変であるが、タイプＣｏｎｔａｉｎｅｒは、書き込み可能であると宣言される、Ｓｔｕｄｅｎｔと呼ばれる入力パラメータを含む。したがって、規則（コンストラクタへの入力が不変許可またはフレッシュ許可を伴う入力パラメータのみを含む場合、オブジェクトは「ｉｍｍｕｔａｂｌｅ」に昇格可能であること）は、このタイプが書き込み可能入力を含んでいるため、不変に昇格するには不適格であるものとみなす。これにより、読み取り可能の最大許可が可能となる。

第２の課題は、不変タイプおよび非不変タイプに対して共通のストレージを定義することである。プログラミングにおいて、記憶された値を元の状態で取り出せるような、任意のオブジェクト用のストレージとすることが可能な場所を定義することが有利である。これは、記憶位置が変更可能タイプおよび不変タイプを受け入れる必要がある場合、両方のタイプに対して作用する可能な許可は存在しないため、失敗に終わる。以下の疑似コードについて考えてみる。
ｗｒｉｔａｂｌｅ Ｓｔｕｄｅｎｔ ｓｔｕｄｅｎｔ＝．．．；
ｉｍｍｕｔａｂｌｅ ｓｔｒｉｎｇ ｎａｍｅ＝．．．；
？？？ｏｂｊｅｃｔ ｓｔｏｒａｇｅ；
ｉｆ（ｃｏｎｄｉｔｉｏｎ）｛
ｓｔｏｒａｇｅ＝ｎａｍｅ；
｝
ｅｌｓｅ｛
ｓｔｏｒａｇｅ＝ｓｔｕｄｅｎｔ；
｝

この例では、「ｓｔｕｄｅｎｔ」および「ｎａｍｅ」の両方からの割り当てが可能であり、それらを元の許可と共に取り出すことが可能な、「記憶」場所に関する許可を選別する方法はない。あらゆる許可に問題がある。たとえば、不変リファレンスを「ｗｒｉｔａｂｌｅ」としてマーク付けされたリファレンスに記憶することはできないため、「書き込み可能」許可は「ｎａｍｅ」が割り当てられないようにする。書き込み可能リファレンスを不変な場所に記憶することはできないため、「不変」許可は「ｓｔｕｄｅｎｔ」が割り当てられないようにする。割り当てた値および取り出した値は、それらがもともと所有していたものとは異なる許可を有することになるため、「読み取り可能」許可は「ｓｔｏｒａｇｅ」が割り当てられないように、および取り出されないようにする。

本明細書で説明する原理は、不変タイプの概念を導入することによって、これらの問題を解決する。これは、タイプのすべてのインスタンスが不変であることを示すために、ユーザがタイプ宣言に追加する明示的注釈である。たとえば、本明細書で説明する原理は、不変タイプが宣言される方法に限定されないが、以下の例示の疑似コードについて考えてみる。
ｉｍｍｕｔａｂｌｅ ｃｌａｓｓ Ｓｔｒｉｎｇ｛
．．．
｝

図３は、本明細書で説明する原理が採用可能な環境３００を示す。（オーサリングプログラムなどの）オーサリングプロセス３１０は、プログラミングまたは（ソフトウェアなどの）他のプログラミングエンティティに、直前にその例が示された不変タイプ宣言３１２を含む（ソースコードまたは中間言語コードなどの）コード３１１を生成させることが可能である。次にコンパイラ３２０がコード３１１をコンパイルし、その結果不変タイプ宣言３１２に遭遇する。

図４は、オブジェクトタイプの複数のインスタンスが不変であることを保証するための方法４００のフローチャートを示す。方法４００は、オブジェクトタイプが不変（イミュータブル）である旨の宣言にアクセスしたとき（動作４０１）、コンパイラによって実行可能である。たとえば図３を参照すると、方法４００は、コンパイラ３２０が不変タイプ宣言３１２にアクセスしたとき実行可能である。

宣言に応答して、コンパイラは、そのオブジェクトタイプの各インスタンスが不変（イミュータブル）として分類される（動作４１１）ように、コンピュータ実行可能命令を自動的に組み立てる（編成する）。これにより、不変タイプのすべての他のインスタンスを暗黙的に「不変」にする。さらに、そのオブジェクトタイプのインスタンスのすべての直接または間接的に到達可能なメンバが、不変として分類される（動作４１２）。たとえば、インスタンスによって直接または間接的に到達可能なすべてのタイプ、フィールド、メソッド、およびプロパティには、暗黙的に不変許可のタグが付けられる。加えて、構築時に、そのオブジェクトのインスタンスのフィールド割り当てが可能ないずれのリファレンスも、作成者がインスタンスにアクセスできるようになる時点を超えて存続し続けることはできない（動作４１３）。例として、コンストラクタにおける「ｔｈｉｓ」の許可には、「未構築」と呼ばれる許可が暗黙的に割り当てられる。この許可は、図２で「未構築」許可２１１Ｅとして示されている。

不変タイプの主要なプロパティは、構築中にそれらの状態を変更することが許されることであるが、構築が完了すると、不変タイプから構築されたいずれのインスタンスも、二度と変更することはできない（したがって不変である）。以下の構築後規則が実施され、１）フィールドは不変であるため、それ自体は変更できない、２）不変タイプのすべての構築済みインスタンスは不変であるため、それらのフィールドを再割り当てすることはできない（フィールドの再割り当てまたは変更を試行したいずれのメンバも、コンパイル時に見つけられることになる）

構築時の変更は、「未構築」許可２１１Ｅ（図２を参照）で達成される。この許可によって、フィールドのターゲットリファレンスからの読み取りおよびターゲットリファレンスへの書き込みが可能になる。不変性の不変部分を維持するために、フィールド割り当てを可能にする「ｔｈｉｓ」リファレンスを、コンストラクタより長持ちさせることはできない。リファレンスが、書き込み可能入力で「未構築」許可と共に記憶され、コンストラクタがオブジェクトをさらに変更することを完了した後に使用されることが可能な場合、問題が生じることになる。さらに、コンストラクタが完了するまで、「ｔｈｉｓ」値を、完全に構築されたＡｄｄｒｅｓｓオブジェクトとして見ることもできない。これによりＡｄｄｒｅｓｓオブジェクトは、依然として変化している場合であっても、不変を装うことができる。以下の疑似コードについて考えてみる。
ｐｕｂｌｉｃ ｉｍｍｕｔａｂｌｅ ｃｌａｓｓ Ａｄｄｒｅｓｓ
｛
ｐｕｂｌｉｃ Ａｄｄｒｅｓｓ（ｏｕｔ ｎｏｔｃｏｎｓｔｒｕｃｔｅｄ Ａｄｄｒｅｓｓ ｐ）
｛
ｐ＝ｔｈｉｓ；
Ａｄｄｒｅｓｓ ａｄｄｒｅｓｓ＝ｔｈｉｓ；
｝
｝

「ｔｈｉｓ」からの上記割り当てのうちのいずれかが合法的である場合、完全に構築されたＡｄｄｒｅｓｓインスタンスを変更しているものとみなすことができる。この「未構築」許可はいずれかの割り当てを防止する。この許可はユーザによって宣言可能でないため、任意の記憶位置に表すことはできない。上記の疑似コード例におけるパラメータ宣言は、コンパイラの観点からは単に非合法である。「未構築許可」を、任意の他の許可タイプに（読み取り可能にも）変換することもできない。これにより、記憶する場所を定義することができないため、コンストラクタよりも長持ちしないことが保証される。

これらの制約は、不変タイプがいったん構築を完了すると、常時不変であることを意味する。したがって、構築済み不変タイプのすべてのインスタンスには、暗黙的に不変許可のタグが付けられる。ユーザがタイプに加える、書き込み可能を含むいずれの許可も、タイプシステムによって単純に無視される。変更が単に可能でないため、許可はもはや関係ない。

インスタンスがいかなる変更も生じさせることができないため、不変タイプのインスタンスを、変更のためにマーク付けされた位置に記憶できるようになる。以下の疑似コードについて考えてみる。
ｓｔｒｉｎｇ ｓ１＝“ｔｅｓｔ”；
ｉｍｍｕｔａｂｌｅ ｓｔｒｉｎｇ ｓ２＝ｓ１；
ｗｒｉｔａｂｌｅ ｓｔｒｉｎｇ ｓ３＝ｓ１；
ｗｒｉｔａｂｌｅ ｏｂｊｅｃｔ ｏ１＝ｓ１；

したがって、これが再度不変タイプおよび変更可能タイプに共通のストレージを可能にする。さらに、不変ではない可能性のあるオブジェクトを不変として安全に分類することが可能であり、不変オブジェクトの使用に関してプロセスが互いに干渉し合うことを気にすることなく、異なるプロセス間でインスタンスを安全に共有することができる。

本発明は、その趣旨または必須の特徴から逸脱することなく、他の特有な形で具体化することができる。説明した実施形態は、すべての点で単なる例示であり、制限的でないものとみなされる。したがって本発明の範囲は、前述の説明ではなく添付の特許請求の範囲によって示される。特許請求の範囲と等価の意味および範囲内にあるすべての変更は、その範囲内に包含される。

Claims (9)

1. オブジェクトタイプの複数のインスタンスが不変であることを保証するための、コンピュータで実装された方法であって、
   ソフトウェアコードにおける宣言であって、オブジェクトタイプへの注釈を含み、かつ、前記オブジェクトタイプが不変であることを指定する宣言にアクセスする動作、および、
   前記宣言へのアクセスに応答して、
   構築されると前記オブジェクトタイプの各インスタンスが不変として分類されるようにするコンピュータ実行可能命令を自動的に組み立てる動作であって、前記コンピュータ実行可能命令は、前記オブジェクトタイプの全てのインスタンスが不変となるように前記オブジェクトタイプに対するユーザにより指定される許可を無視するコンピュータ実行可能命令を含む、動作と、
   前記オブジェクトタイプの前記インスタンスのすべての直接または間接的に到達可能なメンバが、不変として分類されるように、コンピュータ実行可能命令を自動的に組み立てる動作と、
   構築時に、そのオブジェクトの前記インスタンスのフィールド割り当てが可能ないずれのリファレンスも、前記インスタンスの作成者が前記インスタンスにアクセスできるようになる時点を超えて存続し続けることは許可されないように、コンピュータ実行可能命令を自動的に組み立てる動作であって、構築時にそのオブジェクトの前記インスタンスのフィールド割り当てが可能な前記リファレンスの許可には、ユーザにより宣言可能でなく、かつ、任意の他の許可タイプに変換可能でない、許可タイプが割り当てられる、動作と、
   を実行すること、
   を含む、コンピュータで実装された方法。
2. 前記不変オブジェクトタイプの少なくとも１つのインスタンスが１つまたは複数の書き込み可能入力値を取る、請求項１に記載のコンピュータで実装された方法。
3. 前記１つまたは複数の書き込み可能入力値は、全ての前記少なくとも１つのインスタンスにおけるフィールドに記憶されない、請求項２に記載のコンピュータで実装された方法。
4. 前記リファレンスのインスタンスのうちの１つまたは複数のメンバが不変許可でない許可を含む、請求項１に記載のコンピュータで実装された方法。
5. 前記オブジェクトタイプの前記インスタンスのうちのいずれかを変更可能とするメカニズムが存在しない、請求項１に記載のコンピュータで実装された方法。
6. フィールド割り当てを可能にする前記リファレンスが、前記オブジェクトタイプのインスタンスを構築するインスタンスコンストラクタのｔｈｉｓリファレンスである、請求項１に記載のコンピュータで実装された方法。
7. フィールド割り当てを可能にする前記リファレンス上で実行可能な１つまたは複数の動作のセットが、前記リファレンスがフィールドとして記憶されないように制限される、請求項１に記載のコンピュータで実装された方法。
8. 前記１つまたは複数の動作のセットが読み取りおよび書き込みを含む、請求項１に記載のコンピュータで実装された方法。
9. コンピューティングシステムの１つまたは複数のプロセッサによって実行された場合、オブジェクトタイプの複数のインスタンスが不変であることを保証するための方法を前記コンピューティングシステムに実行させる、コンピュータ実行可能命令を有するコンピュータ可読記憶媒体であって、前記方法は、
   ソフトウェアコードにおける宣言であって、オブジェクトタイプへの注釈を含み、かつ、前記オブジェクトタイプが不変であることを指定する宣言にアクセスする動作、および、
   前記宣言へのアクセスに応答して、
   構築されると前記オブジェクトタイプの各インスタンスが不変として分類されるようにするコンピュータ実行可能命令を自動的に組み立てる動作であって、前記コンピュータ実行可能命令は、前記オブジェクトタイプの全てのインスタンスが不変となるように前記オブジェクトタイプに対するユーザにより指定される許可を無視するコンピュータ実行可能命令を含む、動作と、
   前記オブジェクトタイプの前記インスタンスのすべての直接または間接的に到達可能なメンバが、不変として分類されるように、コンピュータ実行可能命令を自動的に組み立てる動作と、
   構築時に、そのオブジェクトの前記インスタンスのフィールド割り当てが可能ないずれのリファレンスも、前記インスタンスの作成者が前記インスタンスにアクセスできるようになる時点を超えて存続し続けることは許可されないように、コンピュータ実行可能命令を自動的に組み立てる動作であって、構築時にそのオブジェクトの前記インスタンスのフィールド割り当てが可能な前記リファレンスの許可には、ユーザにより宣言可能でなく、かつ、任意の他の許可タイプに変換可能でない、許可タイプが割り当てられる、動作と、
   を実行すること、
   を含む、コンピュータ可読記憶媒体。

Images