1

privateまたはモジュールの洗練されたツリーを備えた大きなライブラリパッケージがあると考えてくださいpackage—それを呼びましょうfunnylib。funnylib.fooエンドユーザーが内部モジュール（など）に直接触れることは望ましくないためfunnylib.bar、代わりに外部インターフェイスを提供したいと思います—次のように：

Funnylib.d：

public import funnylib.foo;
public import funnylib.bar;
public import funnylib.baz;

エンドユーザーのようにインポートするだけimport funnylibです。問題は、Dが同時に持つことfunnylib.dを禁止していることです。funnylib/

__init__.pyPythonのように、Dに「デフォルトパッケージモジュール」のようなものはありますか？いいえの場合、上記の設計を行う正しい方法は何ですか？

Update1： ​​iternalモジュールをのようなパッケージに移動することを考えたfunnylib_privateので、funnylib正常にインポートされますが、funnylibが保護されたシンボルにアクセスしなくなりpackage、ファイルレイアウトが不快になるため、保護のコストが低下します（非常に望ましくありません）。

4

2 に答える 2

1

allライブラリをインポートするために文書化されているパブリック インポートを使用して単純なモジュールを作成します。

module funnylib.all;

public import funnylib.foo;
public import funnylib.bar;
public import funnylib.baz;
于 2012-04-05T14:23:30.363 に答える
1

モジュールとパッケージを同じ名前にすることはできません。したがって、たとえば、フォボスは astd/algorithm.dと aを持つことができませんでしたstd/algorithm/sorting.d。std/algorithm.dそしてstd/algorithm衝突するでしょう。行うべき典型的なことは、ラチェットフリークが説明allし、そのパッケージ内のすべてのモジュールをパブリックにインポートするという名前のモジュールを使用することです。しかし、サブモジュールを使用しているという事実を隠したい場合は、単に次のようにすることができます

funnylib.d
_funnylib/foo.d
_funnylib/bar.d
_funnylib/baz.d

どこにも文書化さ_funnylibれていませんが、ddoc ではうまく機能しません。これは、各モジュールの文書を_funnylib生成するためです。生成されるほとんどfunnylib.dの文書はモジュール文書です。文書化するシンボル。モジュールシステムは、あなたがやろうとしているようにモジュールを隠そうとするという考えで設計されていません.

現在、モジュールが大きくなりすぎたときに、モジュールをパッケージにきれいに分割できるようにするための提案が現在議論されています (たとえば、 、 などstd.algorithmに分割するときに、明示的に使用するコードが壊れないようにするため)それは今です）。そして、それが整理されたら、それを使用できますが、ドキュメントは、uber-module ではなく、各サブモジュールに対して行われます。これは実際にはコードを移行する手段として意図されており、モジュールを分割しているという事実を隠そうとするものではありません。これは基本的にモジュールを使用するのと同じですが、パッケージが単一のモジュールであった場合にコードを壊さないようにするためのセマンティック シュガーがあります。std.algorithm.searchstd.algorithm.sortingstd.algorithm.countUntilstd.algorithm.search.countUntilall

于 2012-04-05T17:17:31.157 に答える