ほとんどのインポートは不要ですが、本番用にビルドするときに静的分析ツールを使用してコードを削除するのに役立つため、インポートを使用することをお勧めします。
index.htmlページとindex-debug.htmlページで定義されている2つの「環境」変数があります。ここを参照してください。
OBJJ_INCLUDE_PATHSは基本的に、フレームワーク/ライブラリコードをインポートするときにobjjが検索する場所のリストです。たとえば、次のようにします。
@import <Foundation/CPObject.j>
それ以外の:
@import "Foundation/CPObject.j>
これは、Foundation/CPObject.jがフレームワーク内に存在するためです。したがって、実行@import "Frameworks/Foundation/CPObject.j
はアングルブラケットを使用するのとまったく同じです。
つまり、フレームワークコードを任意のディレクトリに移動し、山かっこ構文を使用することで、実際のパスがなくてもそれらのファイルを見つけることができます。
では、アプリケーションは、直接インポートされていない他のすべてのクラスをどのように認識しますか?さて、私が上でリンクしたインデックスファイルで気づいたなら、objjがmain()を見つけることができる場所を指定する別の行があります。そのファイルの先頭にあるmain.jは、FoundationフレームワークとAppKitフレームワークの両方をインポートします。ここを参照してください。
これらのインポートを追跡すると、CPWindow.jがAppKit.jの109行目にインポートされていることがわかります。
したがって、AppKit.jはほとんどのAppKitをインポートするため、CPWindowに依存するクラス(たとえば)は手動でインポートする必要はありません…しかし、それは確かに害はありません(ファイルが2回インポートされることはありません)。
ただし、AppKitとFoundationは、作成した独自のクラスについて何も知らないため、手動でそれらをインポートする必要があります。