概要 collectionsライブラリのオブジェクト型は、オブジェクトリファレンスや他の値を、構造化コレクションのメンバとして管理する汎用的な基礎を確立します。基本的なコレクション構造体は幅広いものですが、これらはカスタマイズされ、コアとなる少数の型(Array、List、Set、Map)にまとめられています。これらの型は内部実装でなく、インターフェイスによって厳密に定義されます。しかし、特殊なオプションがあり、(他のライブラリの実装のように)効率的で低レベルな利用への柔軟性と制御性を提供します。 |
以下は、<collections.h>にインポートされる他のヘッダファイルです。
#import <defobj.h> |
collectionsライブラリは、defobjライブラリのライブラリインターフェイス規則に従います。また、このライブラリに定義されたクラスと標準スーパークラスにも依存します。collectionsライブラリを初期化すると、defobjライブラリも自動的に初期化されます。defobjもcollectionsライブラリを必要とするため、常に両方ともアプリケーションにリンクされなければなりません。
Swarmの特定のバージョンに対して、明らかな互換性の問題はありません。
このセクションは、まだ利用できません。GridTurtleテストプログラムが、collectionsライブラリの利用法を完全に解説した事例です。あなたが使いたいメッセージやオプションがこのテストプログラムに見当たらなければ、それは実装されていない可能性があります。
利用できません。
collectionsライブラリが完全に実装されるまでは、collectionsの実装クラスから規則をサブクラス化することは確実性に欠けます。一般にこれらのクラスは、ある独立したオブジェクト型を実装するように選択された複数のクラスの、最も複雑な利用のはざまに存在することになります(ライブラリ定義規則に、型とクラスの識別に関するサマリがあります)。そのような実装からのサブクラス化を単純にするため、新しいメソッドが開発されています。その間、もしあなた自身のクラスの実装にコレクションを利用する必要があれば、そのクラスにインスタンス変数を加えてその中にコレクションを置き、クラスで利用したいコレクションのメッセージをこの変数に渡してください。いずれにせよ、基礎となる構造体のすべての利用をコントロールできるため、多くの場合これは良い設計だと言えます。
collectionsライブラリは、オブジェクト指向プログラミングに役立つ最も重要な土台の1つです。ほとんどのオブジェクト指向システムは、汎用collectionsライブラリの少なくともさわりの部分を提供します。たとえばGNUSTEPというプロジェクトは、libobjectライブラリを提供しています(現在はアルファテスト中)。これには、Nextが開発したOpenStepフレームワークのライブラリへの対応を目的とした他のサービスに加えて、collectionsライブラリが含まれています。
Swarmは、そのエージェントシミュレーションフレームワークの特化したニーズに適合するため、独自のcollectionライブラリを実装しています。
利用できません。
ドキュメンテーションと実装の現状
collectionsライブラリはほとんど完全なインターフェイスリファレンスドキュメントを持っており、インターフェイスの設計はほぼ全体に渡って最終版の域に達しています。しかし、collectionsライブラリは、このインターフェイスの高度な機能の多くをまだ実装していません。
Collectionsライブラリの開発は、activityライブラリが必要とする特定の機能に集中してきました。activityライブラリは、スケジュールで実行されるべきアクションをサポートするために、collectionsを使用します。collectionsライブラリ自体は、汎用ライブラリとしての利用に向けて完成されつつあります。
Array型とList型については、すべての基本的な機能が完全に実装されています。Set型とMap型は基本メッセージは定義されていますが、現在のところソート済みリストを使った未熟な実装に頼っています(この実装はactivityライブラリの小さく比較的静的なスケジュール構造に対してより適しており、トラバースされるメンバに変化が発生するときに最も寛大になります)。安定したツリーとハッシュテーブルの両方を使ったさらに効率的な実装を現在開発中です。
現在のOrderedSetは、内部メンバスロットの低レベルなオプションを使うときにのみサポートされており、実装されるメッセージはインターフェイスリファレンスの解説には適合しません。重複メンバのグループに対するサポートは、SetとMapのどちらにもありません。
どの型のコレクションに対しても、制限つき利用モード(たとえばリードオンリー制限)に向けた特別なオプションは実装されていません。StackとQueueは実装されていませんが、それはListの制限つきの利用に過ぎません。idや小さなものを除き、どのメンバ型のサポートもありません(他のメンバ型はdefobjが提供するデータ型ファシリティに依存します)。
不完全とはいえ、実装された機能の一部は実に過酷な検証がなされてきました。SetやMap構造体へのインターフェイスは、それらの基礎をなす実装が改善されてもそのまま残ることになります。したがって、それらの利用に害はありません。collectionsの利用法を完全に例示しているGridTurtleテストプログラムを参照してください。
collectionsライブラリは、defobjライブラリのライブラリインターフェイス規則が示すドキュメンテーション構造に従います。少なくともドキュメンテーションの各セクションには、プレースホルダがあり(単に場所の確保が目的で、そのセクションがまだ利用できないことを示すだけのものもありますが)、すべてのリンクは、そこに何かがあるか否かは別としてかならずどこかにリンクしています。
ドキュメンテーションのあちこちに「(..」ではじまるコメントがあります。これは実装やドキュメンテーションの現況に関する説明です。
どのライブラリのドキュメンテーションについても、最優先すべきは、基本的な能力をすべてまとめたUnixの"man page"に相当するインターフェイスリファレンスドキュメントを完成することです。次に優先されるのは、補足的な"利用ガイド"ドキュメントを完成することです。リファレンスドキュメントと違い、利用ガイドはタスク指向の構成を持っており、実際のコード例を通じて初級ユーザをガイドします。利用ガイドは普通のユーザにとっておそらく必要な、各ライブラリのチュートリアル的な役割を果たします。
利用ガイドのコード例は、まだ開発されていません。当分はテストプログラム(ドキュメンテーションのリリースディレクトリに含まれているGridTurtleテストプログラム)を使用します。このディレクトリはdefobj、collections、activityライブラリの基本機能のコード例を数多く提供しています。また、これらのコード例は新しいリリースのライブラリで走るため、実装が完全になされて機能しているライブラリを確認する目的でも役に立ちます。