This document was encoded by Japanese<Shift-JIS>.
It was made a translation into Japanese with original author's permition.
Archive-name: eiffel-faq
Posting-Frequency: approximately monthly
Last-modified: 09 March1998
この質問と回答のリストは、Usenet のニュースグループである comp.lang.eiffel、comp.answer、そして news.answers へ月刊で投函されます。
訂正、追加、そしてコメントは、どうぞ Franck Arnaud( franck_arnaud@stratus.com )へ送ってください。
この情報は、ベンダーからの情報で補われた、多くの貢献者によって comp.lang.eiffel へ投稿されたものから抜粋し要約したものです。その精度に関しては一切保証しません。
この翻訳は、Franck Arnaud が行っています。配布は、制限しません。この FAQ は、歴代の保守者である Rock Howard、Roger Browne、Conrad Taylor （歴代順）らの偉業の上に構築します。
あなたは、次から、匿名ファイル転送(anonymous FTP)によって最新のコピーを受け取ることができます。
あるいは、次のメッセージを本文に記入し、mail-server@rtfm.mit.edu へ電子メールを送れば受け取れます。
send /pub/usenet/news.answers/eiffel-faq
前回投函した時点からの変更は、次の通りです。
QCOM SmallEiffel under GNU banner. QCOM New versions of ISE and Halstenbach compilers. QCOM Beta of Eiffel/S 2.0 for the Mac. QFRE SmallEiffel now with source code. QGRP Eiffel Forum user group. QWEB Eiffel Forum web site. LCAT Explicitely mention generic types.
QEIF Eiffel って何ですか?
QORI Eiffel は、どこから来たのですか?
QCOM どんな Eiffel コンパイラが利用できますか?
QFRE Eiffel は、フリーあるいはシェアウェアとして利用できますか?
QARC comp.lang.eiffel ニュース グループのアーカイブはありますか?
QBOK Eiffel を学ぶためにどんな本が利用できますか?
QWEB WWW 上では、どこで Eiffel を見つけられますか?
QEDI Eiffel エディタまたはemacs-modeは、どこで入手できますか?
QBON BON って何ですか?
QSAT Sather って何ですか? Eiffel とはどう比較されますか?
QSTD Eiffel 言語のための標準はありますか?
QTGV Eiffel アプリケーションはどのくらい速く走りますか?
QGRP Eiffel のユーザ グループは何かありますか?
QADR Eiffel 製品とサービスはどこで入手できますか?
QCNF Eiffel ユーザーのためのカンファレンスは何かありますか?
QECC Eiffel のほとんどの実装は、どうして C 言語にコンパイルするのですか?
QJVM Eiffel のJava へのコンパイラをどこで入手できますか?
LFEA Eiffel は、どんな特徴を持ちますか?
LCHN Eiffel の言語定義には、どんな変更がありましたか?
LLIB Eiffel には、どんなライブラリがありますか?
LDBC 事前条件と事後条件についての大いなる扱いって何ですか?
LCON どうぞ、covariance と contravariance を説明し議論してください。
LCAT Eiffel の型システムに「抜け穴」があるというのは、本当ですか?
LTSK Eiffel には並行性のためのサポートはありますか?
LOVL Eiffel は、どうして関数のオーバーローディングを許さないのですか?
LPRC Eiffel に手続きの型が無いのは、何故ですか?
LATR Eiffel にクラス属性が無いのは、何故ですか?
LPAR 再定義されたルーチンの親クラスバージョンを、どうしたら呼出せますか?
LEVC Eiffel と他の言語との比較を、どこで見つけられますか?
LDES Eiffel には、何かデストラクタはありますか?
LDIS 多重継承を効果的に実装するには、どうしたらよいですか?
Eiffel は、先進的なオブジェクト指向プログラミング言語であり、高品質で再利用可能なソフトウェアの設計と構築に重点を置いています。
Eiffel は、他のどんな言語の上位版でも拡張でもありません。Eiffel は、オブジェクト指向プログラミングを強力に奨励し、C や C++ といった他の言語へインターフェイスするけれども、前世代の言語からの危険な実践<practice>を許しません。Eiffel は、ソフトウェアの正しさを向上させるために、「契約による設計<design by contract>」の概念を支援します。
言語の面を越えて、Eiffel は、ソフトウェア構築の一手段として捉えることもできます。Eiffel は、初級のプログラミング コースを含む、ソフトウェア教育のための優れた乗り物<vehicle>です。
Eiffel は、バートランド・メイヤ<Bertrand Meyer>さんによって考案され、カリフォルニア州ゴレタにある Interactive Software Engineering (ISE) という彼の会社で開発されました。
メイヤ博士は、オブジェクト指向プログラミングでの広範囲にわたる経験、特に Simula での経験を借り入れてきました。また、彼は、ソフトウェア検証とコンピュータ言語定義に関する学際的作業から、その重要な概念へ加えました。
Eiffel の設計は、ソフトウェア エンジニアが複雑なソフトウェアを創造するときに直面する、多くの実践上の関心事を扱います。Eiffel は、1985年9月14日における最初の着想と1986年の最初の導入のときから、継続的に改良されてきています。
Eiffel は、エッフェル塔を設計した技術者である Gustave Eiffel さんにちなんで名付けられました。
次の Eiffel コンパイラは、現在利用可能であり、そのベンダーまたは作者によってサポートされています。この一覧は、最初の発行日の順に並べてあります。
商用の製品の場合、プラットフォームや使用条件（個人か専門家か）などに依存して条件が変わりうるので、価格は示しません。最新の価格情報については、どうぞ、ベンダーのウェッブ サイトを調べてください。一般的な傾向として、コンパイラの限定版あるいは個人用は、50米ドルから200米ドルまでの費用ですが、シングル ユーザ ライセンスでロイヤルティ フリーの配布権がある完全版のコンパイラは、主流のプラットフォームに関しては、 200 米ドルから 1500 米ドルの範囲です。
下記の一覧で、「target(対象)」の項目は、どのコードがコンパイラによって生成されるかを示します。大部分の --しかし全部ではない-- コンパイラは、C 言語のコードを生成するので、サポートされる C 言語のコンパイラが必要なこともあります。
「platform(プラットフォーム)」の項目では、サポートされるプラットフォームを表示します。「Win32」は、Intel x86 上の Windows 95 と Windows NT を意味します。私たちの最善の知識でも、RISC プラットフォーム上の Windows NT の下で利用可能なコンパイラは一つもありません（しかし、間接的に SmallEiffel があります）。「Unix」は、さまざまな Unix 群を意味しており、プラットフォームの実際の一覧については、ベンダーを調べてください。Unix をサポートしている大部分のベンダーは、Intel x86 上の Linux をサポートしています。
「概説」の節は、ベンダーのウェッブ ページから抜粋したものです。
Vendor: Interactive Software Engineering Inc, USA
Product: ISE Eiffel (最新版: 4.2)
Licensing conditions: 商用、期限付きのフリーの評価版
Target: C
Platforms: Win32, Unix
Web: http://www.eiffel.com/
概説:
ISE Eiffel の環境は、次のものを含みます。
Vendor: Tower Technology Corporation
Product: TowerEiffel (最新版: 2.0)
Licensing condition: 商用
Target: C
Platforms: Win32, Unix
Web: http://www.twr.com/
概説:
TowerEiffel は、次のものを含む完全な環境です。
Vendor: Dominique Colnet et al
Product: SmallEiffel the GNU Eiffel compiler (最新版: -0.82)
Licensing conditions: フリーウェア (GPL)
Target: ANSI C / Java Virtual Machine
Platforms: Any ANSI C machine
Web: http://www.loria.fr/SmallEiffel/
概説:
SmalEiffel は、広範囲のプラットフォームで利用可能な、小さくて非常に高速なフリーな
Eiffel コンパイラですが、完全であることを意図しています。Eiffel の C 言語へのコンパイラ、Eiffel
の Java バイトコードへのコンパイラ、文書化ツール、整形印刷を含みます。
SmallEiffel は、システム分析全体に関わる革新的な戦略を使用しており、その戦略は、伝統的なコンパイラのインクリメンタルなコンパイルよりも、しばしば高速にコンパイルすることを可能にします。
この戦略は、もともと1994-1995年にフランスのナンシーにある LORIA 研究所で設計され、1995年9月から多くの個人や大学によって世界規模で使用されてきました。
Vendor: Halstenbach ACT GmbH, Germany
Product: iss-base (最新版: 2.0)
Licensing conditions: 商用
Target: C
Platforms: Win32, Unix
Web: http://www.halstenbach.de/
概説:
iss-bench は、MS Windows と UNIX の下での Eiffel プログラムの開発のための、相互作用的でプラットフォーム依存のツールです。その特徴は、インクリメンタルなコンパイル、依存性の自動認識、ソース
コード デバッガ、そしてブラウジング ツール群です。
ライブラリは、次のものを含みます。 iss-baselib (データ構造)、 iss-vision
(Windows API サポートと、複雑なダイアログを作成するための一連のさらに抽象化したものとを提供するユーザ
インターフェイス管理システム)、iss-store (関係データベース群とのインターフェース)。
（注意事項：iss-bench と iss-baselib は、ISE Eiffel をベースにしていますが、ISE Eiffelと同じものではありません。iss-vision と iss-build は、ISEの製品とは無関係です。）
Vendor: Object Tools GmbH, Germany
Product: Visual Eiffel (最新版: 2.0)
Licensing conditions: 商用、機能限定のフリーの評価版
Target: Native Intel x86
Platforms: Win32 only
Web: http://www.object-tools.com/
概説:
Visual Eiffel と DM(Display Machine) の使用は、あなたが複雑な Windows のアプリケーションを非常に短期間で開発するのを助けるでしょう。Visual Eiffel は、あなたに次のものを与えます。
Eiffel の他のコンパイラは、どんなサポートもなかったり、古いバージョンであったり、あるいは開発の初期段階であったりするけれども、いずれ言語の実装が完全になるかもしれないので、言及する価値があります。
SmallEiffel は、フリーウェアのコンパイラであり、大部分の ANSI C プラットフォーム上でコンパイルできる高度にポータブルな C 言語のパッケージを提供します。（Eiffel 内の）コンパイラ自体の完全な Eiffel のソースコードは、入手できません。
多くの商用ベンダーは、何らかの制限が付いた無償の評価版を提供しています。また、商用ベンダーは、しばしば、Intel ベースの PC 上の Win32 のようなポピュラーなプラットフォームのために、廉価な入門レベルのバージョンを持っています。
Title: Object-Oriented Software Construction, second edition Author: Bertrand Meyer, ISE Inc. ISBN: ISBN 0-13-629155-4 - Prentice Hall 1997 Short:
この本は、オブジェクト技術の全般に関する包括的なリファレンスであり、設計原理から、オブジェクト指向技術、契約による設計、オブジェクト指向分析、並行性、永続性、抽象データ型、そしてそれ以上に及びます。この分野の開拓者によって書かれたので、方法論的問題と技術的問題の両方について深くつっこんだ分析を包含しています。
「Eiffel 本」として提供されていない（Eiffel は、概念を解説するために使用した「表記法」として提供されている）にも関わらず、どんな Effelist にとっても本質的な読み物であり、そして実際に、「表記法」--Eiffel-- の完全な記述を含みます。
CD-ROM に含まれてくるもの: 容易な参照のための完全なハイパーリンク テキスト、業界の主要なプラットフォーム上で文書を読むためのソフトウェア、補足的な素材（再利用可能なコンポーネント、数学の補足）、そしてこの本の概念を支援する完全なグラフィカル オブジェクト指向開発環境。
Title: Eiffel: The Language Author: Bertrand Meyer ISBN: ISBN 0-13-247925-7 -- Prentice Hall 1992 Short:
この本は、Eiffel の紹介、言語のリファレンス、そして壮大な哲学を600ページに結合します。これは、厳格で包括的な本であり、メイヤ博士の表現の明快さにも関わらず、ある読者は先に進むのが厳しいと思うかもしれません。それは、最も権威のある言語リファレンスであり、すべての真面目な Eiffel ユーザにとって本質的な読み物です。第二版以降のもの（ISBNコードは同じ）を手に入れてください。それは、多くの訂正と変更（第二編はなく、現在何も進行してません）を含みます。この本は、フランス語でも利用できます（ISBN 2-7296-0525-8）。
Title: Object Oriented Programming in Eiffel, 2nd edition
Author: Pete Thomas and Ray Weedon -- ISBN: 0-201-33131-4 -- AW 1997
Short: この本は、非常に包括的な Eiffel のチュートリアルかつ教科書であり、
堅固な「抽象データ型」のアプローチによるものです。
Title: Algorithms and Data Structures Author: Jeffrey Kingston -- ISBN: 0-201-40374-9 -- AW 1997 Short: 計算機科学中心のアルゴリズムとデータ構造を扱い、完全な Eiffel の実装を含みます。
Title: An Object-Oriented Introduction to Computer Science Using Eiffel Author: Richard Wiener -- ISBN: 0-13-838725 -- PH 1997 Short: None
Title: Object Technology for Scientific Computing Object-Oriented
Numerical Software in Eiffel and C
Author: Paul Dubois -- ISBN: 0-13-267808-X -- PH 1996
Short: CD に、UNIX と Linux 環境のための Free Eiffel が付いています。
Title: Object-Oriented Software Engineering with Eiffel
Author: Jean-Marc Jezequel -- ISBN: 0-201-63381-7 -- AW 1996
Short: Eiffel の包括的な案内書。Eiffelの説明に加えて、この本は、
市場で利用可能なコンパイラとライブラリの説明と比較を含みます。
Title: Object Structures: Building OO Software Components with Eiffel
Author: Jacob Gore -- ISBN: 0-201-63480-5 -- AW 1996
Short: これは、言語の学習へ導く、Eiffel のための初めての「データ構造」の本であり、
どんなプログラミング言語でも最も重要な話題の一つであり、初めて包括的に扱いました。
Title: Eiffel Object-Oriented Programming Author: John Tyrrell -- ISBN: 0-333-64554-5 -- 1995 Short: これは、安価で非常に取っ付きやすい本です
Title: Software Development Using Eiffel: There can be life other than C++
Author: Richard Wiener -- ISBN: 0-13-100686-X -- PH 1995
Short: これは、他のオブジェクト指向言語での基礎学力を伴う例に対する、
たくさんのコードの例を伴った有用な本です。
Title: Object Success
Author: Bertrand Meyer -- ISBN: 0-13-192833-3 -- PH 1995
Short: この本は、オブジェクト指向、その企業への衝撃、そしてソフトウェア プロセスの
リエンジニアリングのための利用へ、管理者向けの案内書です。
Title: Object Oriented Programming in Eiffel Author: R. Rist and R. Terwilliger -- ISBN: 0-13-205931-2 -- PH 1995 Short: これは、設計に重点を置いた教科書です。
Title: Seamless Object-Oriented Software Architecture: Analysis and
Design of Reliable Systems
Author: Kim Walden and Jean-Marc Nerson -- ISBN: 0-13-031303-3 -- PH 1994
Short: この本は、ビジネス・オブジェクト表記(Business Object Notation ,BON)法を
詳細に説明します。
Title: Reusable Software: The Base Object-Oriented Component Libraries
Author: Bertrand Meyer -- ISBN: 0-13-245499-8 -- PH 1994
Short: この本は、ライブラリ設計の原則と基礎的な計算構造の分類法を説明します。
EiffelBase ライブラリの手引書として役立ちます。
Title: An Object-Oriented Environment: Principles and Application
Author: Bertrand Meyer -- ISBN: 0-13-245507-2 -- PH 1994
Short: この本は、「溶けつつある氷(Melting Ice)」というコンパイル技術と EiffelBuild
という GUI アプリケーション ビルダーと同じくらい、ISE EiffelBench 環境を説明します。
Title: Object-Oriented Applications
Author: Meyer and Nerson editors -- ISBN: 0-13-013798-7 -- PH 1993
Short: この本は、Eiffel 技術の紹介に続けて、Eiffel で書かれた大規模アプリケーションの
深くつっこんだ七つの説明を含みます。
Title: Eiffel: Objektorientiertes Programmieren in der Praxis Author: Frieder Monninger -- ISBN: ISBN 3-88229-028-5 -- 1993 Short:この本は、非常に実際的な、ドイツ語による Eiffel の手引書です。
Title: Eiffel: An Introduction
Author: Robert Switzer -- ISBN: 0-13-105909-2 -- PH 1993
Short: この本は、多くのコードの断片と二つの堅固な Eiffel アプリケーションを伴った、
とても明快で簡潔な Eiffel の入門書です。フランス語でも利用可能です（ISBN 2-225-84-656-1）。
Title: Object Oriented Software Construction, first edition
Author: Bertrand Meyer -- ISBN: 0-13-629049-3 -- PH 1988
Short: 上で言及した第二編の初期の編であり、言語の前バージョンに基づいています。
フランス語、ドイツ語、イタリア語、dutch語などでも利用可能です。
出版社は、Addison Wisley は AW 、そして Prentice Hall は PH です。
Eiffel ホームページ。Wales College 大学の Cardiff のサーバーに収容されています。
Eiffel Forum というユーザ グループのウェッブ サイトは、フリーなソフトウェアの貯蔵庫と現在のプロジェクトに関する情報とを含みます。
Geoff Eldridge さんの Eiffel ページ。GUERL、Eiffel Liberty のプレビュー、オンライン ジャーナル、オンライン C++ 診断、そして他の有用な情報を含みます。
http://www.totalweb.co.uk/gustave/
Gustave は、Everything Eiffel の Roger Browne によって保守されている Eiffel 資源の宝箱です。
主要ベンダーのウェッブサイトは、次です。
Halstenbach ACT http://www.halstenbach.de/
ISE http://www.eiffel.com/
Object Tools http://www.object-tools.com/
Tower Technology http://www.twr.com/
[目次へ]
QEDI: Eiffel エディタまたはemacs-modeは、どこで入手できますか?
Tower Technology 社は、Eiffel 3 emacs mode を供給しています。これは、構文向けの強調表示と自動的字下げをサポートし、フォントの使用、色、そして字下げの量を容易にカスタマイズできます。それは、TowerEiffel システムのポート<port>として供給されますが、それを要求する人は誰でも自由に利用できます。 最新版を入手するには、elisp@atlanta.twr.com へ電子メールを送ってください。
WINEDIT というシェアウェアのプログラマ用エディタは、色による構文の強調を提供し、 MS-Windows 下の Eiffel/S で動作し、すべての主だったシェアウェア アーカイブから入手できます。
Alan Philipsさんのフリーの Programmers File Editor は、同じく MS-Windows 下の Eiffel/S で動作し、テンプレートを持ちますが、構文の強調はありません。http://www.lancs.ac.uk/people/cpaap/pfe/ から入手できます。
Franck Arnaud さんの、 Eiffel コードを色付けする Premia の実装からの、Windows/WindowsNT プログラマ向けエディタである Codewright への Eiffel 拡張版は、整然とした字下げといくつかのテンプレートを持っています。 http://www.altsoft.demon.co.uk/free/ から入手できます。
BON ("Business Object Notation"「ビジネス オブジェクト表記」)は、高水準の分析設計のための手法であり、継ぎ目が無く逆戻り可能な、Eiffel の実装への移行を提供します。この手法は、契約による設計と体系的な開発に重点を置いています。
ISE は、EiffelCase というツールで BON をサポートしています。
Sather は、カリフォルニア州バークレイの ICSI で新たに作成されたオブジェクト指向言語であり、もともと Eiffel の後から様式化されたものですが、今は非常に異なっています。
Sather は、契約による設計を支援しませんが、他の興味深い特徴をいくつか持っています。Usenet のニュースグループ comp.lang.sather、あるいは Sather のホームページ http://www.icsi.berkeley.edu/~sather/ を見てください。
Eiffel 言語の定義は、パブリック ドメインです。この定義は、NICE(Non-profit International Consortium for Eiffel、「Eiffel のための非営利の国際コンソーシアム」)によって統制されています。
Eiffel の商標は、NICE によって所有され統制されています。NICE は、言語の初期定義として、Bertrand Meyer さんの「Eiffel: The Language」(第二刷)という本を使用しています。
1995年6月に、NICE は、Eiffel Library Kernel Standard (ELKS、「Eiffel ライブラリ カーネル標準」)の初版（「Vintage 95」と呼ばれる）を発行しました。標準のクラスと特徴だけを使用する、Eiffel アプリケーションのこれらの部分は、ELKS-95 をサポートするどんなコンパイラ上でも最小限の変更で走るはずです。
1998年の NICE の常任委員は、Eric Bezault、James McKim、Bertrand Meyer、Christine Mingins、そしてFrieder Monninger です。
NICE の電子メール アドレスは、nice@atlanta.twr.com です。
Eiffel の初期の実装は遅かったです。最近の実装は、劇的に改善されています。しかしながら、どんな Eiffel の実装下でも最大のパフォーマンスを達成するために、実行時の表明の監視は、オフに切り替えなければなりません。
一般的に言うことは困難ですが、C++ と比較して、単純な計算中心のアプリケーションは、おそらく 15% 以上遅く走るでしょう。大規模なアプリケーションは、しばしば、計算というよりも記憶管理によって左右されます。ゴミ集めの効果は、度々議論される点であり、一般的に負荷はまったく低い(10%)ものであり、原則的にゴミ集めを前提とするプログラミング スタイルは、一般的な手作業による記憶管理よりも効率的であるにちがいありません。このことはまた、アプリケーションの種類、ゴミ集めの実装などに依存します。
'Eiffel Forum' は、Eiffel に関心を持つ個人のために、新たに形成された組織です。主目的の一つは、Perl CPAN に類似して、利用者またはベンダーが開発した資源、再利用可能なコンポーネント、そして幅広く多様な利用者コミュニティへアクセス可能な情報の支援を行うための、ウェッブの基盤を築くことです。
ウェッブサイトは、http://www.eiffel-forum.org/ にあります。
コンパイラ ベンダーは、通常、彼らのユーザ ベースのためにユーザ グループを走らせており、しばしばメーリング リストやカンファレンス期間中のミーティングの形態を取ります。より詳細な情報については、個々のベンダーに接触してください。
次のベンダー、リセラー、そしてEiffel のトレーニングとコンサルタントの供給者は、アルファベット順で一覧にしてあります。
AUSTRALIA
Class Technology Pty. Ltd.
POST PO Box 6274, North Sydney NSW 2060, Australia
TEL +61 2 9922 7222 FAX +61 2 9922 7703
EMAIL eiffel@class.com.au WEB http://www.class.com.au/
EUROPEAN UNION
Advanced Media Technology Ltd.
POST Box 16, Hatolantie 140, SF-34 301 Kuru, Finland
TEL +358 400 620 236 FAX +358 3 4737 117
EMAIL jukka.haukijarvi@eiffel.fi
WEB http://www.eiffel.fi/
Cap Gemini France, ITMI APTOR, Eiffel Group
POST 86-90 rue Thiers, F-92513 Boulogne-Billancourt Cedex, France
TEL +33 1 4910 5300 FAX +33 1 4910 5102
EMAIL eiffel@capgemini.fr
Eiffel Software Iberica
POST Isabel II, 4, 1D; 20011 San Sebastian, Spain
TEL/FAX +34 943 472108
EMAIL jipferur@si.ehu.es
Eiffel Ireland
POST 45 Hazelwood, Shankill, Co Dublin, Ireland
TEL +353 1 282 3487
EMAIL sparker@eiffel.ie WEB http://www.eiffel.ie/Eiffel/
Enea Data
POST Box 232, Nytorpsvagen 5, S-183 23 Taby, Sweden
TEL +46 8 638 5000 FAX +46 8 638 50 50
EMAIL eiffel@enea.se WEB http://www.enea.se/
EtnoTeam
POST Via Adelaide Bono Cairoli 34, I-20127 Milano, Italy
TEL +39 2 261621 FAX +39 2 26110755
EMAIL sales@etnomi.it WEB http://www.etnomi.it/
Everything Eiffel
POST 6 Bambers Walk, Wesham PR4 3DG, England
TEL & FAX +44 1772 687525 WEB http://www.eiffel.demon.co.uk/
EMAIL roger@eiffel.demon.co.uk
Halstenbach ACT GmbH
POST Breidenbrucher Strasse 2, D-51674 Wiehl, Germany
TEL + 49 2261 9902 0 FAX +49 2261 9902 99
EMAIL info@halstenbach.de WEB http://www.halstenbach.de/
Langmack & Partner, Feinarbeit
POST Gitshinner Strasse 91 - 2. Hof, D-10969 Berlin, Germany
TEL +49 30 616794 61 FAX +49 30 616794 67
EMAIL langmack@feinarbeit.de
Object Tools GmbH
POST Zu den Bettern 4, D-35619 Braunfels, Germany
TEL +49 6472 911030 FAX +49 6472 911031
EMAIL eiffel@eiffel.de WEB http://www.eiffel.de/
Jan Willamowius
POST Rueckertstr. 27, D-22089 Hamburg, Germany
TEL +49 40-20981888
EMAIL jan@janhh.shnet.org
WEB http://swt-www.informatik.uni-hamburg.de/~1willamo/dl.html
Information and Math Science Lab Inc.
POST 2-43-1, Ikebukuro, Toshima-ku, Tokyo 171
TEL +81 3 3590 5211 FAX +81 3 3590 5353
EMAIL fushimi@imslab.co.jp WEB http://www.imslab.co.jp/
NEW ZEALAND
Objective Methods Ltd
POST PO Box 17356 (77 Chamberlain Rd)
Karori, Wellington, New Zealand
TEL +64 4 476 9499 FAX +64 4 476 9237
EMAIL dkenny@actrix.gen.nz
SWITZERLAND
Abstraction
POST Faubourg de l'Hopital, CH-2000 Neuchatel, Switzerland
TEL +41 32 7250493 FAX +41 32 7259857
EMAIL abstraction@access.ch
UNITED STATES OF AMERICA
Halstenbach ACT, Inc.
POST 827 State Street, Santa Barbara, CA 93101, USA
TEL +1 805 568 0023 FAX +1 805 884 0806
EMAIL info@halstenbach.de WEB http://www.halstenbach.de/
Interactive Software Engineering, Inc
POST ISE Building, 2nd floor, 270 Storke Road, Goleta, CA 93117, USA
TEL +1 805 685 1006 FAX +1 805 685 6869
EMAIL info@eiffel.com WEB http://www.eiffel.com/
Object Tools, Inc.
POST 13267 Summit Sq. Center, Route 413 & Doublewoods Rd,
Langhorne, PA 19047, USA
TEL/FAX +1 215 504 0854
EMAIL info@object-tools.com WEB http://www.object-tools.com/
Tower Technology Corporation
POST 1501 Koenig Lane, Austin, TX 78756, USA
TEL +1 512 452 9455 FAX +1 512 452 1721
EMAIL tower@twr.com WEB ttp://www.twr.com/
ここに一覧したカンファレンスは、Eiffel のためだけのものではありません。Eiffel は、C++ 言語や Smalltalk を含む他のオブジェクト指向言語と一緒にスポットライトを共有します。
TOOLS は、オブジェクト指向技術のアプリケーションへ捧げられた国際的カンファレンスです。ユーザ グループやNICEの会合といった他のイベントは、しばしば TOOLS と結合して収容されます。http://www.tools.com/ 。
オブジェクト指向のプログラミング システム、言語、そしてアプリケーションに関する ACM SIGPLAN のカンファレンス(OOPSLA)は、おそらく、オブジェクト指向技術についての最大規模の技術カンファレンスです。OOPSLA のホームページは、http://www.acm.org/sigplan/oopsla/ にあります。
ECOOP は、オブジェクト指向プログラミングのための年に一度のヨーロッパのカンファレンスです。http://www.iam.unibe.ch/ECOOP/ 。
対象言語として C 言語を使用することによって、Eiffel の実装は、次のことが可能となります。
Eiffel を、相対的に使用を単純にさせ実装をより困難にさせる多くの技術（C 言語への Eiffel コンパイラは、ネイティブのPascal コンパイラよりも、多分４、５倍、難しいです）。
Eiffel を C へコンパイルすることは、Unix の下ではうまくいくように思えます。C は、ときどき、Unix のネイティブ コードとして考えられています。
一方で、C 言語は、他のプラットフォーム上で普遍的ではなく、そしてEiffel 購入者は、もしサポートされた C コンパイラが Eiffel コンパイラの新バージョンで変更されるならば、同じく C 言語のコンパイラを買うか、もしかしたらリプレースする必要があるかもしれません。
ネイティブ コードのコンパイラをもってすれば、あなたは、より良いスループットと、より小さな実行可能プログラムに対する潜在能力と、わずかにより良いパフォーマンスを手に入れるかもしれません。
Java が流行になっているので、誰もが、お気に入りの言語を JVM(Java 仮想機械)のバイトコードにコンパイルされることを望んでいます。Java と Eiffel との間に総合的な相互運用性をもたせて、このプラットフォームへの Eiffel のコンパイルを提供することについて考えることは、いま魅力的なことです。
残念ながら、ものごとは、最初に思ったほど単純ではありません。Java と Eiffel のオブジェクト モデル間の根本的な違いがあります（動的対静的のオブジェクト システム、単一対多重の継承、契約対願望的思考による設計が、問題の中にあります）。
もちろん Eiffel から（チューリング マシンである）JVM へのコンパイラーを提供することは可能ですが、それは必ず費用、つまりパフォーマンスか相互運用性、あるいはその両方に行き着きます。
書かれた言語を気にすることなく Java で書かれたクラスと Eiffelのクラスを自由に混在させたりマッチさせたりすることを可能にする、JVM
への Eiffel コンパイラを持つことは、見込みなく遥か未来のことです。
それにもかかわらず、大部分のコンパイラ ベンダーは、ベンダーに依存する制限と実装の戦略とを区別しながら、JVM に対する何らかのサポートを提供することに向かって動いています。
SmallEiffel は、JVM 上で何らかの有用な結果をもたらすのに利用可能となった最初のコンパイラです。ISE とObject Tools は、Java をサポートする努力を進めているとアナウンスしました。Pirmin Kalberer は、JVM へのJava コンパイラの初期バージョンを提供しています。
Eiffel は、純粋なオブジェクト指向の言語です。そのモジュール性は、クラスに基づきます。それは、信頼性を強調し、契約による設計を容易にします。それは、設計とプログラミングを共に接近させます。それは、ソフトウェア コンポーネントの再利用を促します。
Eiffel が提供するものは、クラス、多重継承、多態、静的型付けと動的束縛、総称（制約されるものと制約されないもの）、洗練された例外機構、契約によるプログラミングを促進するための表明の体系的使用、そして、高水準の設計と分析のための実装を延期<defered>されたクラスです。
Eiffel は、優美な設計とプログラミング スタイルを持ち、学ぶのが容易です。
概要は、次のページで利用できます。
http://www.eiffel.com/doc/manuals/language/intro/
Eiffel は、まだ、相対的に新しい言語であり、その定義にいくつもの変更がありました。
"Object-Oriented Software Construction"の発行、つまり1988年の第一版と Eiffel 2.3 のリリースの間に、重大な変更がありました。
より重大な変更は、今日使用されている言語の現在かつ唯一のバージョンである Eiffel 3 の導入でもたらされました。これらの変更は、"Eiffel: The Language" に要約されています。
"Eiffel: The Language" の第一刷と第二刷の間に、いくつかのあまり重大ではない変更がありました。
他にも多くの(より些細な)変更がありました。Neil Wilson は、マイクロソフトのリッチ テキスト フォーマット(RTF)とASCII の両方で、ftp://ftp.cm.cf.ac.uk/pub/eiffel/Docs に、要約しました。
すべてのベンダーは、Eiffel Library Standard のカーネル クラスのサポートを目指しています。
加えて、広範囲なライブラリ クラスは、コンパイラとともに供給されており、データ構造、グラフィックス、字句の分析と解析、入出力、永続性、フォーマッティング、そしてもっと多くのものを含んでいます。
さらなる詳細については、ベンダーに接触してください。
大いなる扱いとは、それが契約によるプログラミングを支援するということです。たとえば、事前条件（require句）は、入力引数が有効であることと、要求された操作を行うためにオブジェクトが適正な状態にあることとを検査するために使用される、単純な真理値を記したものです。もしそうでないなら、例外が生成されます。同じように、事後条件（ensure 句）は、メソッドがその義務、つまり呼出し元との「契約を完全に満たすこと」、を正常に実行したことを確実にさせます。不変条件(invariant)は、オブジェクトのメソッドが別のオブジェクトへ返る時に毎回検査される真理値式です。
あなたは、どんなオブジェクト指向のプログラミング言語においても、これらのアイデアを使用できますが、通常は、独自の表明機構を提供するか、プログラマの行動原理に頼らなければなりません。Eiffel において、このアイデアは、その環境の組み立てすべてへ統合されます。私たちは、それらを以下によって見つけられます。
将来に、私たちは、技術がその方法を表明能力へ差し込む形式的手法を見ることを期待しています。これは、正しくあるべき(to be put into place<?>)より強力な制約を先進的に許すでしょう。加えて、もしメイヤ博士による推測が実を結ぶならば、事前条件の考えは、並列プログラミングの開発のための重要な機構へ拡張するかもしれません。
次の場面をよく考えてください。つまり、私たちは、二つのクラス PARENT と CHILD を持っています。CHILD は、PARENT から継承し、そして PARENT の特徴 'foo' を再定義します。
class PARENT
feature
foo (arg: A) is ...
end
class CHILD
inherit
PARENT redefine foo end
feature
foo (arg: B) is ...
end
ここで質問です。'foo' への引数の型、つまり、'A' と 'B' に、どんな制限が置かれるでしょうか？（もしそれらが同じであるならば、問題はありません）
二つの可能性があります。
(1) B は、A の子でなければなりません。(covariant<?>規則 - こう名付けられているのは、子クラスにおいて、再定義されたルーチンにおける引数の型が、親のルーチンにおける型の子であるからであり、継承は同じ方向で両方に対して「varies<?>」します。)
(2) B は、A の親でなければならない(contravariant<?>規則)
Eiffel は、covariant<?>規則を使用します.
まず最初に、contravariant<?>規則は、理論的に主張しているように見えます。思い出してください。多態性は、属性がその宣言された型のオブジェクトだけでなくどんな子孫（子）の型のオブジェクトでも保持できる、ということを意味していました。動的束縛は、属性上の特徴の呼出しが、属性の宣言された型の子孫であってもよいオブジェクトの「実際」の型のために、対応する特徴の呼出しを誘発するであろう、ということを意味します。Contravariance<?>を用いて、私たちは子孫の型のオブジェクトを属性へ割り当てることができ、さらに、子孫が少なくとも祖先の引数と同じくらい一般的に特徴の引数を対処できるから、すべての特徴の呼出しが働くでしょう。事実、同じく、子孫オブジェクトは、あらゆる点で、祖先オブジェクトの完全に有効な実例でもあります。つまり、私たちは、サブタイピングを実装するために継承を使用しているのです。
しかしながら、実世界のアプリケーションのプログラミングにおいて、私たちは、頻繁に、関連したクラスを共同で特化する必要があります。
一つの例があります。この例では、PLOT_3D は PLOT から継承し、そして DATA_SAMPLE_3D は DATA_SAMPLE から継承します。
class PLOT
feature
add(arg: DATA_SAMPLE) is ...
class PLOT_3D
inherit
PLOT redefine add end
feature
add(arg: DATA_SAMPLE_3D) is ...
このことは、convariant<?>規則を要求し、Eiffel では上手く働くでしょう。
もし私たちが PLOT_3D オブジェクトを PLOT 属性へ置き、DATA_SAMPLE をそれに加えようとしたならば、失敗するでしょう。それが失敗する理由は、私たちが、サブタイピングというよりはむしろコードの再利用を実装するために継承を使用したのに、あたかも子孫オブジェクトが真のサブタイプであったかのように子孫クラスのオブジェクト上の祖先クラスの特徴を呼出したからです。実行時の型エラーの可能性を避けるために、このエラーを見つけ出し排除することは、コンパイラの仕事です。
実世界の状況がconvariant<?>な解決策を提案する、著者による例があります。草食動物<herbivore>は、草<grass>を食べます。牛<cow>は、草食動物です。草は、植物<plant>です。牛は、草を食べますが、他の植物を食べません。
class HERBIVORE class PLANT
feature
eat(food: PLANT) is ...
diet: LIST[PLANT]
class COW class GRASS
inherit inherit
HERBIVORE PLANT
redefine eat
end
feature eat(food: GRASS) is ...
これが、私たちの望むものです。コンパイラは、私たちに、COW(牛)オブジェクトを HERBIVORE(草食動物)属性に置き、PLANT(植物)をエサにしようとすることから止めさせなければなりませんが、私たちは、どんな場合でもこんなことをしようと試みていてはいけません。
同じく、コンテナ 'diet' をよく考えてください。私たちがこの特徴を子孫クラスにおいて再定義することを強制されないのは、'eat' への引数のconvariant<?>な再定義を用いて、特徴 'diet' がいつも食べられうる（たとえば、牛については牧草）どんなオブジェクトも包含できるからです('eat' への引数のconvariant<?>な再定義を用いて、コンテナ 'diet' の型をより一般的にするために親クラスを再オープンする必要があったでしょう)。
要約するために、 実世界の問題は、しばしば、それ自体をconvariant<?>な解決策へ導きました。Eiffel は、これらを上手く処理します。convariant<?>な引数の再定義の直前にある不正なプログラムは、コンパイラがそれらを捕捉しない限り、実行時の型エラーを引き起こしえます。
Sather は、contravariant<?>規則を使用しますが、サブタイピングとコード再利用のために別の機構を使用し、真のサブタイプ上の動的束縛を許すだけです。これは、contravariance<?>を上手く働かせるように見えますが、Sather のプログラマに、convariant<?>なプログラムをモデリングするときに具象型を使用するように強制することができます。具象型は、Sather においては、さらにサブタイプ化できないので、これは、再利用に対する潜在能力を減少させることができます(Eiffelでは、どんな型もさらにサブタイプ化できるが、コンパイラは、それが有効に使用されていることを検査しなければなりません)。
いいえ。Eiffel の設計は、コンパイル時にすべての型エラーを捕捉することを可能にするので、Eiffel のプログラムは、実行時の型エラーで異常終了<abort>することはありえません。
しかしながら、コンパイル時にある特定の、より不明瞭な型エラーのクラスを捕捉するために、コンパイラは、一つずつ各クラスを見ながらというよりは、クラスがシステム全体の中で相互作用する方法を分析しなければなりません。
容易に検査することができないエラーに、主なタイプが二つあります。
(a) LDBC の質問にあるような、ルーチンの引数の??covariantな再定義。
(b) 子孫クラスにおけるエクスポートの制限。
(c) 総称クラスの型に適合している ??covariant な用法標示(LIST[ANY] と LIST[STRING]
における 'put' のように)。
もし受け入れられるなら、提案された進行中のものがあります。これは、コンパイラに、毎回システム全体ではなくクラスを見ることによって、エラーのこのクラスを増分的に検査することを許すでしょう。
システム規模のコンパイル時の有効性検査は複雑になりえるので、今日利用できるコンパイラで、完全な静的型検査を実装するものは一つもありません。あるものは、実行時検査のコードを挿入します。一方、システムレベルの有効性の問題が発生しうる場合は、実際に主要な困惑ではないので、あまり頻繁ではありません。
Eiffel は、Interactive Software Engineering (ISE)によって定義されたように、最新の言語仕様において並行性をサポートしています。並行性に関するより完全な記述 --SCOOP モデル-- は、バートランド・メイヤさんによる "Object Oriented Software Construction 2ed" で見つけることができます。また、いくつかの文書は、ISE のウェッブ サイトにある http://www.eiffel.com/doc/manuals/technology/concurrency/ から入手できます。
また、いくつかのコンパイラは、SCOOP の、独立してマルチスレッドするための多様な形式をサポートします。
Eiffel において、クラスの各自のシグニチャにも関わらず、クラスの二つの特徴が同じ識別性を持つものはありません。これは、関数のオーバーローディング（多重定義）の使用、つまり、C++ のような言語における共通のプログラミング技法を妨げます（「多重の多態性」）。
Eiffel は、最小であるように設計されています。つまり、正確に、その設計者が必要であると考えた特徴を含み、それ以外のものを含まない、ということです。
Eiffel は、すでに、その継承システムを通じて（単一の）多態性をサポートしているから、関数のオーバーローディングがあなたを受け入れるという実証的なことだけが、あなたが学ばなければならない特徴の名前の数を減らしています。これは、誤り（しばしば、型エラー）に罠をかけるためにコンパイラの能力を減少させることの代償です。
また、可読性は、オーバーローディングが可能でないときに、拡大されます。オーバーローディングを用いると、あなたは、特徴が呼ばれて成し遂げうる前に、対象の型と同じくらい引数の型を考慮する必要があるでしょう。多重継承と動的束縛を用いれば、これは、コンパイラにとって厄介で、人間にとってエラーになりがちです。「最も近い」ルーチンが無い、ルーチン呼出しを明確にするために使用することができた、直感的な規則は一つもありません。
しかしながら、Eiffel において、最も一般的で適用可能な型の引数を持つ一つのルーチンを書き、引数の実行時の型に応じて適正な操作を成就するために、割り当て試行の演算子を使用することは簡単です(それによって、明確化の「規則群」を正確にプログラミングすること)。
これまで述べてきたのは、次のようなことです。多重の多態性の欠落は、私たちに厄介な方法でいくつかの共通な数学的な演算（たとえば、行列演算）を書くことを強制し、そして、算術な式(「算術的均衡規則」、 ETL p385)を特殊に扱うように強制します。しかし、全体として Eiffel の品質を改善する、それほど単純で、優雅で、有用な解決策をもたらした人は誰一人いません。
ルーチンへの引数として渡されることをルーチンに許す際の考えは、オブジェクト指向手法と非互換な、大勢の人の見方にあります。オブジェクト指向の定義は、あらゆる操作がオブジェクトの型に属すので、それ自体によってだけではルーチンを操作<manipulate>しない、ということを暗に意味します。
ルーチンの引数を使用する必要性を感じるときの可能な技法は、クラスを書き、その中にルーチンを含めることです。それから、（ルーチンの引数を渡すというよりは、むしろ）ルーチンが適用されうるオブジェクト -- このクラスの実例 -- を渡します。これは、長期的に、より柔軟なアプローチです。たとえば、あなたは、あとで、あなたのルーチン - ルーチンを包含しているクラス - へ、「undo（取消）」というルーチン、あるいは「最後に実行した時」といった属性を加えることもできます。
Eiffel において、「once」 関数は、より素晴らしい機能性を、より原則に基づいた方法で提供します。「once」関数の本体は、システムごとに（クラスの実例ごとではなく）一度だけ、最初に呼出されたときに、実行されます。その後は、「once」関数は、その本体を再実行することなく、同じ Result（結果）を返します。
「once」関数は、それゆえ、（その最初の使用時に初期化された）参照型の共有された属性を実装するために使用できます。
「once」関数は、mixin クラス内に含むことができます。それから、その once 関数によって返された、共有された属性は、その mixin クラスから継承するクラスのすべての実例へ利用可能になります。
継承されたルーチンが子クラスで再定義されるとき、再定義されたルーチンが親クラス内のバージョンを呼出す方法がありますか？
1) もしあなたが親クラスの設計に責任があるならば、そうした必要性を予想することもできます。あなたは、凍結された（再定義不可能な）いくつかのバージョンで、同じルーチンの本体の複数のバージョンを提供することもできます。
class PARENT
feature foo, frozen parent_foo is
do
...
end
end
class CHILD
inherit
PARENT
redefine foo
end
feature foo is
do
parent_foo
...
end
end
2) そうでなければ、あなたは、'foo' の二つのバージョンを取得するために反復された継承を使用し、それらの一つを再定義します。
class PARENT
feature foo is
do
...
end
end
class CHILD
inherit
PARENT
rename foo as parent_foo
end
PARENT
redefine foo
select foo -- (動的束縛の場合)
end
feature
foo is
do
parent_foo
...
end
end
3) 可用なこれらの構成要素の両方はその制限を持つ一方で、提案は、それらをより直接的な解決策で置き換える方法に基づきます。つまり、新たに予約された単語 Precursor であり、その本体内で再定義されたルーチンの親バージョンを呼出すことを許すものです。ルーチンが二つ以上の Precursor を持つという稀な場合に、その呼出しは、どの Precursor が呼出されるかを指定するために限定できます。
この提案の下で、例は、次のようになります。
class CHILD
inherit
PARENT
redefine foo
end
feature
foo is
do
Precursor - 直前バージョンを呼ぶ
...
end
Richard Wienerさんの本 "Software Development Using Eiffel: There can be life after C++" (Prentice-Hall, ISBN 0-13-100686-X)にあります。
Ian Joyner さんの "C++ critique" は、C++、Eiffel、そして他の言語との比較を含んでいます。それは、次の URL にあります。 http://www.progsoc.uts.edu.au/~geldridg/cpp/cppcv3.html 。
あなたはまた、ISE のウェッブ サイト http://www.eiffel.com/doc/manuals/technology/oo_comparison/ で、Eiffel、C++、Java、そして Smalltalk の比較を見つけることができます。
Eiffel のオブジェクトはゴミ集めされるので、ソフトウェア開発者が、いつどうやって「消滅<destroy>」させるのか、あるいはソフトウェアのテキスト内でそれらを「開放<free>」するのか、ということについて気にする必要はありません。
いくつかの実装は、どうしても手作業でオブジェクトを取り除きたいと思っているプログラマのために、「開放<free>」手続きを提供しています。そのような手続きは、「あなた自身のリスクでの使用」であり、通常の Eiffel 開発では必要とされません。
通常の使用方法に戻って、その必要性は、ある特定の操作が、ゴミ集めがオブジェクトを再生利用するかどうかを自動的に起こるであろう、ということを保証するために、持ち上げられるかもしれません。たとえば、もしファイルを記述している Eiffel のオブジェクトが到達不能になり、それゆえ、ついにゴミ集めされるならば、あなたは、物理的ファイルがその時点でクローズされるということを保証することを望むかもしれません。Eiffel のいくつかの実装は、その目的のための仕組みを提供します。それは、カーネル ライブラリのクラス MEMORY からの 'dispose'(使い捨て) 手続きです。
ゴミ集めは、オブジェクトを収集するときはいつでも、そのオブジェクト上の 'dispose' を呼びます。その手続きは、デフォルトでは何もしません（そのため、スマートなゴミ集めは、もちろん、どんな実際の呼出しを実行することも避けるでしょう）。しかし、どんなクラスも MEMORY から継承し、ファイルをクローズすることといった、ふさわしい動作を実行するために 'dispose' を再定義してもかまいません。そのような動作は、ときどき「後始末"finalization"」と呼ばれます。この技法は、便利にそれを達成します。
ゴミ集めが、不達になったオブジェクトを再生利用するといった保証は無いので、'dispose' の安全な再定義は、Eiffel のオブジェクト構造自体ではなく、ファイル記述子、データベース要素、ウィンドウのシステム資源などといった、外部資源に関して動作するだけであるべきです。
C++ 言語あるいは単一継承の言語を背景に持つ人は、しばしば、古典的なディスパッチ テーブル スキーマ（ここでは、あらゆる多態的な特徴は、祖先の多態的な特徴の固定された位置を使用するどんなコードも中断すること無しに、子孫がカスタマイズできるポインタ テーブル内に固定された位置を持つ）を用いて実装できないことを理由に、多重継承がペナルティをもたらす、と考えています。
多重継承を理由とするパフォーマンス問題を被らないことを Eiffel に許す、継承を実装するための他の方法があります。
両方の場合に、私たちは、システム内のあらゆる型が整数の識別子 -- 型識別<type ID> -- を割り当てられている、と仮定することが必要です。
一つ目の実装は、「まばらなマトリクス<sparse matrix>」モデルです。あらゆる多態的な特徴は、型識別によって索引付けされた、それぞれの型のためのエントリを持つ、関連したポインタ テーブルを持ちます。これは、すべての多態的な呼出しに、単一ポインタの違い<?>の（同じ）費用で実行することを許します。
このことのすぐな欠点は、むしろ、大きなデータ テーブル（システム内のすべての型ごとの、すべての多態的なルーチンのマトリックス）を生成する、ということです。幸いなことに、型識別を注意深く選択することによってこのテーブルを効率的に圧縮することを許す、まばらなマトリクスのアルゴリズムがあります（明白な最適化は、型識別のスペースの短いセクションだけが扱われる必要があるので、すべての子孫を親の次にグループ化するように試みることです。）。
他の手段は、まったく異なり、具象的な型ごとにふさわしい静的な関数を呼出して、型識別に関する検索ステートメントの等価性を使用します。この場合に、コンパイラがシステムの大域的な知識を必要とすることは明らかです。つまり、それぞれの多態的なルーチンの呼出しについて、システム内で現実に使用されている、すべての具象的なサブタイプと、そのルーチンのすべての再定義とを知る必要があります。
最初に見たときは、検索ステートメントがシステムをスローダウンさせると考えられます。この解決策を使用する実際のコンパイラは、最初の手段を使用して実装されたものと同じくらい（あるいは、それ以上）効率的でありえる、ということを証明しました。
いま、両方の手段について、コンパイラがコンパイル時に -- あるいは、少なくとも最適化時には -- 完全なシステムのビューを持つことが必要である、ということが明らかになったはずです。これは、まじめな制限のように思われましたが、あまり関係はありません。なぜなら、Eiffel コンパイラは、静的ルーチンと多態的ルーチン -- Eiffel においては、すべてのルーチンが潜在的に多態的である -- を区別できるために、最初の段階でこのビューを持たなければならず、コンパイルされたシステムを適正に実行するために実施しなければならないからです。