問題タブ [name-collision]

クラスが同じ名前の 2 つの抽象メソッドと同じ識別子を持つ 2 つの定数を持つ 2 つのインターフェイスを実装するコードを書いています。

今では、Java 7 の時点で、抽象メソッドに関する限り、名前の衝突を心配する必要がないことを知っています (そうですか??): 適切な実装を提供するだけで問題ありません (共有するすべてのメソッド同じ名前はカバーされています)、そのため、複数の継承のような問題や「ダイヤモンド」は発生しません (これは、Java 8 に到達したときに対処することになると思います)。

しかし、定数に関する限り、2 つのインターフェイスを実装し、VALUE フィールドにアクセスしようとしない場合、コンパイラは文句を言わないことに気付きました。

どうですか？これは正常な動作ですか？それらのメンバーにアクセスした場合にのみエラーが発生しますか?

編集つまり、インターフェイスを実装しようとすると、コンパイラがあいまいさについて警告しないのはなぜですか?

トップレベルの名前空間\Outer があり、別のサブ名前空間\Outer\Inner があり、別のトップレベルの名前空間があるとします\Inner

そして、私はこのよう\Outerに使用するクラスでInner

ではどのインナーを使うか？

または

\トップレベルの名前空間ではオプションであるとphpが言ったので、私は混乱していますか?

Kotlin の可視性修飾子に関する公式ドキュメントでは、マークされたパッケージ レベルの要素はprivate、それらが宣言されているモジュールでのみ可視であると述べています。

したがってA、 で宣言されたクラスModule1.ktは では表示されませんModule2.kt。Module2.ktしかし、独自のクラスに追加しようとするとA、Redeclaration: Aエラーが発生します。

のクラスにアクセスできないのに、名前を自由に使用できないのはModule2.ktなぜですか?Module1AA

このバグ レポートAVRO-1814をきっかけに、この問題を Java の最小限の例に絞り込みました。これは単にエフェクトの核心を示しています。

これをコンパイルしようとすると、

AVRO では、コードが生成され、人々が予期しない名前を選択することがあるという前提の下で、名前の衝突を回避しようとする必要があります。

したがって、この例では、

1. 衝突を避けるために、「test()」メソッドの完全修飾クラス名が必要です。
2. 変数「nl」は、スキーマ定義で使用される名前です。
3. _nl__ のようなフィールドを生成し、getter と setter を使用すると、nl フィールドは常に public であるため、下位互換性が失われる変更になります。

人に「そんなことはやめなさい」と言う以外に。

これらの競合を回避する解決策はありますか?

この質問を引き起こした AVRO バグについては、回避策を見つけたことに注意してください。ここで私は「一般的な答え」を探しています。

Linux<ncurses.h>ヘッダーは関数metaを定義し、C++ メタプログラミング ライブラリmetaはそのすべてのコードをグローバル名前空間に置きますmeta。

同じ C++ プログラムで両方を使用するにはどうすればよいですか (必ずしも同じ TU である必要はありませんが、それは良いことです)。名前の衝突を回避する方法はありますか?

脆弱な回避策が 2 つありますが、簡単に壊れてしまいます。

• 回避策 A:

  ncursesはコンパイルされますが、シンボルはグローバル名前空間にあると予想されるため、リンクに失敗する可能性があります。

• 回避策 B:

  metaライブラリがそのシンボルのいずれかがグローバル名前空間にあると想定しない場合にのみ機能するため、非常に脆弱です。つまり、ライブラリがシンボルを内部的に明確にする必要があり、その::meta::symbol_nameために使用する場合、このアプローチは機能しなくなります。